Re: New file patch (was: Re: Just a Matter of Style (was: LaTeX file handling))
Lars Gullik Bjønnes wrote: "Arnd Hanses" [EMAIL PROTECTED] writes: | (Often used instead of/to emulate pipe: Sorry, I'm only a casual | programmer, so I've always problems to use the correct terminology. | Grateful for any hints.) Xdvi should just watch the file for changes. It might have some problems when the file is deleted and later regenerated with a different inode number. (or equiv) But this is nothing that LyX should care about, this is all handled between LaTeX and Xdvi. Lgb Sorry, but I don't think that it is all handled by LaTeX and Xdvi. LaTeX and Xdvi are children of LyX and directed by LyX to the internally computed hidden tmp-directory. I'm aware of that effect: If I close a file and reopen it again, then I have to close my running Xdvi too, because it is useless now, when using update-dvi. If I start Xdvi again it works ok. But there is no mystery. LyX creates a new tmp-directory (as I can see with /bin/ls) and starts working there. The update-dvi operation creates the new dvi file in the new tmp-dir. latex doesn't delete and recreates the dvi file, the contents of the dvi file will be replaced by latex/tex. Greets, Stephan Witt --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: New file patch (was: Re: Just a Matter of Style (was: LaTeX file handling))
Arnd Hanses wrote: On 31 Aug 1999 17:57:55 +0200, Lars Gullik Bj°nnes wrote: Stephan Witt [EMAIL PROTECTED] writes: | LaTeX and Xdvi are children of LyX and directed by LyX to the | internally computed hidden tmp-directory. I'm aware of that | effect: If I close a file and reopen it again, then I have to | close my running Xdvi too, because it is useless now, when using | update-dvi. If I start Xdvi again it works ok. But there is no | mystery. LyX creates a new tmp-directory (as I can see with /bin/ls) | and starts working there. The update-dvi operation creates the | new dvi file in the new tmp-dir. | | latex doesn't delete and recreates the dvi file, | the contents of the dvi file will be replaced by latex/tex. Yes, and this should be now problem. Xdvi should not care (too much) that the file it views suddenly disappears. Ok, the xdvi is now defunct. Do you mean that it would be better if LyX killed the xdvi when it destroys teh buffer? IMHO killing before any defunct is the cleanest solution and avoids problems. Otherwise you'll leave behind abandoned zombie-like processes haunting your box (shudder :-) Sorry for the late response. I was 2 days not online (travelling to customer). I don't think it's a real problem with "zombie-like" running xdvi's. 1. You can see them. You can regularily quit them. You can decide yourself when to do so. 2. If I quit LyX, then Xdvi is left running too and I'm sure there're users who wants to leave this behaviour untouched. A possible solution may be 1. to document the current behaviour and/or 2. kill (with asking the user?) the running "defunct" xdvi and start a new one when the user selects "View-dvi" or "Update-dvi" from menu Greets, Stephan Witt --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Jean-Marc Lasgouttes wrote: "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars fwrite is essentially fprintf without buffering. So it should be Lars no problem switching to fprintf. (actually fprintf are Lars preferrable because of the buffering) fwrite was used instead of fprintf because it is supposedly faster, I think. Another reason to use this call may be the more prompt error detection of the write operation. But you check them, see below. Lars BUT it is strange, both fwrite and fprintf are conforming to Lars ANSI C. Could it be that we are missing a file.close or a Lars file.flush ? The file.close() is there. Is the file.flush() necessary? The flush shouldn't be necessary. But I think, testing the return codes and errno after fwrite/fprintf is really the best solution to find an explanation for such error conditions. Maybe there are various test effects and the file system was full when testing fwrite while it has some space when using fprintf... There are always curious side effects to look for. But a bug in Solaris 2.6 I would search for at last ressort only. --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: About cxx and types incompatibility
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
|
| | "Me" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| |
| | Me Yes. And friend extern "C" too. It says cxx: Error:
| | Me ../../../lyx-devel/src/mathed/math_panel.h, line 43: linkage
| | Me specification is not allowed friend extern "C" int
| | Me peek_event(FL_FORM *, void *); --^
what happens if you infront of class BitmapMenu ...
inserts a
extern "C" {
int peek_event(FL_FORM *, void *);
}
??
I'm following the discussion with interest, because I'm a
LyX-user on Solaris compiling with SunSoft's CC.
AFAIK the problem with mixing C and C++ is the general
incompatible implicit use of the this pointer in C++ funktions.
Everywhere in X you have a problem with C++ callback funktions.
Maybe you can solve it with static member functions.
I didn't read the source in question of this discussion, but
the general rule of thumb when using C from C++ is to wrap
the function declaration part in the header of the C interface with
extern "C" {
... header text ...
}
as used to see in the xpm header or the define and use of
#define _XFUNCPROTOBEGIN extern "C" {
and
#define _XFUNCPROTOEND }
in X11/Xfuncproto.h
The function pointer typedefs are outside of the extern "C" part.
Stephan
---
[EMAIL PROTECTED] | beusen unternehmensgruppe senkel
fon: +49 30 549932-62 | Landsberger Allee 392
fax: +49 30 549932-29 | 12681 Berlin, Germany
---
Re: LyX 1.0.4.
Jean-Marc Lasgouttes wrote: "Stephan" == Stephan Witt [EMAIL PROTECTED] writes: Stephan As usually I compile on Sun-Solaris and have some trip-wires Stephan to detect. I'll send an excerpt of my terminal output... The Stephan output where warnings "bar hides foo::bar" was the only Stephan warnings I have clipped. Hello JMarc, Thanks for your input. I believe that much problems have been taken care of. What version of CC do you use? If it is 5.0, then I'll be very interested to know what happens on the latest prerelease. We've made a lot of changes there, and are not sure how CC fares. Sorry, I can't help you out with CC 5.x experience. We're using a lousy old version here. % CC -V CC: SC4.0 18 Oct 1995 C++ 4.1 % I had no time to compile the latest prerelease (1.1.x?). I'll try it sometimes in the future (maybe next week). The discussion about supported compilers was very interesting to read, I was not engaged enough to tell something about it. But my opinion is near to John Weiss's (and yours?): "The leeding edge is the bleeding edge". Two years are a long time in the Linux-Environment. But for some people the clocks are not so fast and upgrading is not everywhere for free! I have to spend money for a 2nd machine if I want to upgrade my productive environment savely without the possible headache of loosing my running environment. The most frustrating thing to me is free software which compiles ONLY with Linux-Development-Kits. Stephan PS. I'm subscribed to the lyx-devel list. The post to the lyx-users list was a mistakenly reply to the announcement of LyX 1.0.4 --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: Table size
Juergen Vigna wrote:
Hi Stephan!
Yes, I don't need WYSIWYM too. Normally it is irrelevant
where the linebreak inside the cell text occurs if the cell
width is given.
You'll see that in the new tabular-inset I already have a WYSIWYM view
of the tabular and you're also able to set paragraph layouts in there :)
But what I missed is the possiblity to enter expressions
as column width like 0.2\textwidth. This is sometimes more
convinient then absolute column width.
Yes this may be convenient, but then I'm not able anymore to check the
User input and this is only a input a advanced LaTeX user can give and
for this you also can use the Extra options and give p{0.2\textwidth} as
column type and IMO this is enough.
I was almost sure, there is a way. But I couldn't detect it. Thank you.
I accept the reason for the limitation. I would extend the list of possible
units on user input, i.e. \textwidth and so on. But there is an endless
loop, maybe.
I cannot compile LyX anymore on my Sun box, so I cannot make
a patch to change that... :(
What problems do you have? Maybe Jean-Marc can help you, he still compiles
on Sun Box IMO.
No. For that I have to give Jean-Marc an account and access to my machine to
install the needed compiler to help me :)
It's just the problem with the old Sun-Compiler. My company has to update
the beast to a newer one. If I want to use the Gnu-Compiler, I have to install
it in
my rare time and make sure to not use it for the commercial software
development.
So, I decided to stop compiling LyX until I have more time or a better compiler
from Sun. (And I'm using 1.0.1 on my Sun and 1.1.4 an my Laptop)
Jürgen
P.S.: I forward this to the User-List too maybe someone is interested ;)
Yes ofcourse. I forgot to CC to the list. And then I was too lazy
to forward this and write an explanation...
voila' you solved this as elegantly as possible. :)
Stephan
---
[EMAIL PROTECTED] | beusen unternehmensgruppe senkel
fon: +49 30 549932-62 | Landsberger Allee 392
fax: +49 30 549932-29 | 12681 Berlin, Germany
---
Re: sigc++ configure.in
Andre Poenitz wrote: I had the same problem under Solaris 2.6. The problem is only bash looks in the current directory, sh and ksh don't. The lines in configure.in should be changed to . ./configure (worked for me) Well, I believe it worked for you, but I do not believe that there is any sh/ksh/whatever that does not interpret ./configure as "run the script/binary named 'configure' in the current directory" The only difference between "./configure" and ". ./configure" is that the latter works even if ./configure has no executable permissions set. So maybe it's a permissicon problem, it certainly has nothing to do with having . in $PATH or your choice of shells. I think, you're right with the example above. But you're wrong with the problem originally given by Michael Frankowski. There was the line . ac_threads.sh which caused the grief. It should be ". ./ac_threads.sh". Greets, Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: bug report
Angus Leeming wrote: JMarc Angus Reading an old lyx file with current CVS, I notice that JMarc Angus protected blanks are converted to SpecialChar \- rather than JMarc Angus SpecialChar ~ JMarc I do not see that with a file created with LyX 1.0.3 (read correctly JMarc with both cvs and 1.1.5fix). Do you have an example file? No, of course not! (:-) I had an old file (not too old; I've only been using lyx for 6 months!) that had a few things such as Appendix-1 when I opened the file today. They should have been Appendix_1. (Was a blue bash, should have been the protected space.) Of course, I only noticed this after I'd been editing the file for a while and saved things a few times, so my original is no more and I've no idea what the original lyx file contained (ie what lyx code. It was written originally to be a protected space.) Presumably, therefore, this is now a useless bug report. It may crop up again in more useful guise. Hi, maybe it was a file, with the "temporary" protected blank? Don't remember the exact intermediate value (\SpecialChar \protected_separator?). Regards, Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: More about LyX meeting
Jean-Marc Lasgouttes wrote: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Dear Jean-Marc, I spent some time outside of my office, so I couldn't respond... Jean-Marc So, I know have the following table for our next meeting: Update: 13 14 15 16 17 18 19Laptop JMarcX X X X X X X X (and a PC and more if needed) Lars X X X X X X X X AndréX X X X X X (possibility of a second one) Michael X X Juergen X X X X X José X X X X X X X Martin Andreas Angus Stephan x x x x (one or two of these days) Won't come after all: Asger. As you can see, I am still waiting for confirmation from Martin, Andreas, Angus and Stefan. Stefan, I remember you plan to come just for a day, but I do not remember which one :) I stay from the 8th of July til 20th of July in Paris together with my wife and my children (2) and we'll be guests of our friends. So there is no need to care for us. But I have to see what our plans are. Currently there is a meeting at the 14th planned already. I propose to talk about the details in July. Regards, Stephan --
Re: [Bug 1656] command gnome-session-save kills lyx!
Hello Lars,
You had a simple fix that avoids the crash, didn't you Stephan?
yes I have.
Yesterday I came back to Berlin and since today I'm online again...
After a vacation of 2 weeks I have to do some real work.
But I'll provide the patch shortly. In Paris I failed to
compile the patched version because of an incomplete
update or bad precompiled headers or whatever, I don't
know. So I didn't check it in (with Michaels account).
Now it compiles again and I send you the patch.
Regards,
Stephan
--
Index: src/frontends/qt2/lyx_gui.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/lyx_gui.C,v
retrieving revision 1.86
diff -u -p -r1.86 lyx_gui.C
--- src/frontends/qt2/lyx_gui.C 2005/07/16 15:55:35 1.86
+++ src/frontends/qt2/lyx_gui.C 2005/07/22 11:38:42
@@ -51,6 +51,7 @@
#endif
#include qapplication.h
+#include qsessionmanager.h
#if QT_VERSION = 0x030100
#include qeventloop.h
#endif
@@ -114,6 +115,7 @@ class LQApplication : public QApplicatio
public:
LQApplication(int argc, char ** argv);
~LQApplication();
+ void commitData(QSessionManager sm);
#ifdef Q_WS_X11
bool x11EventFilter (XEvent * ev) { return lyxX11EventFilter(ev); }
#endif
@@ -140,6 +142,28 @@ LQApplication::~LQApplication()
if (locked())
unlock();
#endif
+}
+
+
+void LQApplication::commitData(QSessionManager sm)
+{
+ /// Maybe someone should do something sensible here.
+ /// The implementation is required to avoid an application exit
+ /// when session state save is triggered by session manager.
+ /// The default implementation sends a close event to all
+ /// visible top level widgets when session managment allows
+ /// interaction.
+ ///
+ /// Following is a (currently not working) proposal...
+ /// The problem is a blocking application when
+ /// BufferList::quitWriteAll wants to open the question
+ /// alert message dialog.
+ /// Qt doesn't return from it and no box is opened.
+ /// if ( sm.allowsInteraction() ) {
+ /// if ( !bufferlist.quitWriteAll() ) {
+ /// sm.cancel();
+ /// }
+ /// }
}
Re: William Leeming
Angus Leeming wrote: I'd like to announce the arrival of William who arrived on Tuesday 15 November, weighing in at 3.55kg (7lb 12oz in old money.) Congratulations, especially to your wife. It wasn't easy getting him out (40 hours labour followed by a Cæsarian) but now he is out both he and Emma are doing really well. That was really hard, I hope the medicine men did it all well. I've put together a few pictures to satisfy your curiosity: http://www.lyx.org/~leeming/William/ It's not a very professional-looking page but, hey ho, it should give you a flavour. Very nice... Stephan
Re: bug 1656
Juergen Spitzmueller wrote: http://bugzilla.lyx.org/show_bug.cgi?id=1656 Shouldn't this patch be applied? Personally, I don't get the described patch, but Martin has confirmed that the problem is solved by the patch. Jürgen Just in case nobody knows... I have no karma to apply it. Stephan ---
Re: bug 1656
Jean-Marc Lasgouttes wrote: Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen http://bugzilla.lyx.org/show_bug.cgi?id=1656 Shouldn't this Juergen patch be applied? Personally, I don't get the described Juergen patch, but Martin has confirmed that the problem is solved by Juergen the patch. The only question I have about this patch is whether we lose something when the session is closed while LyX is running and there are unsaved files. What happens with or without the patch? I'm comiling the cvs-updated 1.4.x tree now. I'll answer your question tomorrow, I hope. Stephan ---
Re: bug 1656
Jean-Marc Lasgouttes wrote: Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen http://bugzilla.lyx.org/show_bug.cgi?id=1656 Shouldn't this Juergen patch be applied? Personally, I don't get the described Juergen patch, but Martin has confirmed that the problem is solved by Juergen the patch. The only question I have about this patch is whether we lose something when the session is closed while LyX is running and there are unsaved files. What happens with or without the patch? Hi JMarc, as promised yesterday I did some testing today. The results are disappointing... I cannot reproduce the crash on gnome-save-session anymore. But I online-updated my system since then and I did an cvs-update too. I'm sure that my qt-libraries were changed by the online-updates. What the cvs-update did... I guess it has not changed the situation regarding this bug. With the patch the unsaved changes remains unsaved. Without the patch I was asked to save the changes. So far seems all well, but after playing a while with gnome-save-session I now have the same behaviour as in Paris, the qt-library is unable to open the question box anymore! Even worse, I have to kill the lyx process to be able to do any work. All gnome applications are locked. It seems this is caused by the running gnome-save-session which is waiting for lyx returning from user response - what never happens. Now I'm unable to do further testing. I'll do some investigation at home til Monday. Stephan
Re: bug 1656
Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan as promised yesterday I did some testing today. Thanks. Stephan With the patch the unsaved changes remains unsaved. Without Stephan the patch I was asked to save the changes. So far seems all Stephan well, Is this really what we want?? Yes, I meant to say: the behaviour is ok without the patch. The program should ask for saving the changes. And it shouldn't terminate. Stephan but after playing a while with gnome-save-session I now have Stephan the same behaviour as in Paris, the qt-library is unable to Stephan open the question box anymore! Even worse, I have to kill the Stephan lyx process to be able to do any work. All gnome applications Stephan are locked. It seems this is caused by the running Stephan gnome-save-session which is waiting for lyx returning from Stephan user response - what never happens. From reading the Qt doc about QSession, I do not see clearly how it is supposed to work... Last weekend I did some further investigation. 1. Checking the behaviour of kwrite it opens a question box to save the changes when it gets the focus... Hm... when it is iconized or on another desktop it doesn't ask? Really strange. 2. Checking the patched lyx it blocks the process of saving sessions completely. Really bad. The backtrace when interrupted from inside the debugger looks like the following: Program received signal SIGINT, Interrupt. 0xe410 in ?? () No breakpoints or watchpoints. #0 0xe410 in ?? () #1 0xbfffd648 in ?? () #2 0x085193f4 in ?? () #3 0x08519270 in ?? () #4 0x40b4af9d in ___newselect_nocancel () from /lib/tls/libc.so.6 #5 0x401dee8a in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #6 0x40249e51 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #7 0x402338bf in QApplication::enter_loop () from /usr/lib/qt3/lib/libqt-mt.so.3 #8 0x40f99bef in DCOPClient::callInternal () from /opt/kde3/lib/libDCOP.so.4 #9 0x40f99edc in DCOPClient::callInternal () from /opt/kde3/lib/libDCOP.so.4 #10 0x40f9a137 in DCOPClient::call () from /opt/kde3/lib/libDCOP.so.4 #11 0x40f9a198 in DCOPClient::call () from /opt/kde3/lib/libDCOP.so.4 #12 0x40f5f044 in initializeIntegration () from /opt/kde3/lib/kde3/plugins/integration/libqtkde.so #13 0x401bc86f in QKDEIntegration::initLibrary () from /usr/lib/qt3/lib/libqt-mt.so.3 #14 0x401bc8d5 in QKDEIntegration::enabled () from /usr/lib/qt3/lib/libqt-mt.so.3 #15 0x40451e95 in QMessageBox::information () from /usr/lib/qt3/lib/libqt-mt.so.3 #16 0x08216e2f in prompt_pimpl ([EMAIL PROTECTED], [EMAIL PROTECTED], default_button=0, cancel_butto n=2, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at Alert_pimpl.C:44 #17 0x0820db82 in Alert::prompt ([EMAIL PROTECTED], [EMAIL PROTECTED], default_button=0, escape_bu tton=2, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at Alert.C:44 #18 0x080bcad9 in BufferList::quitWriteBuffer (this=0x83f0ac4, buf=0x853e648) at bufferlist.C:83 #19 0x080bcca6 in BufferList::quitWriteAll (this=0x83f0ac4) at bufferlist.C:122 #20 0x08251e7e in LQApplication::commitData (this=0x83f4320, [EMAIL PROTECTED]) at lyx_gui.C:151 #21 0x401bef8c in QSessionManager::QSessionManager () from /usr/lib/qt3/lib/libqt-mt.so.3 #22 0x401bf061 in QSessionManager::QSessionManager () from /usr/lib/qt3/lib/libqt-mt.so.3 #23 0x4094ccc1 in _SmcProcessMessage () from /usr/X11R6/lib/libSM.so.6 #24 0x4095b26e in IceProcessMessages () from /usr/X11R6/lib/libICE.so.6 #25 0x401bf3b4 in QSmSocketReceiver::socketActivated () from /usr/lib/qt3/lib/libqt-mt.so.3 #26 0x401bf425 in QSmSocketReceiver::qt_invoke () from /usr/lib/qt3/lib/libqt-mt.so.3 #27 0x40294e7e in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0x402954ad in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0x405e91f0 in QSocketNotifier::activated () from /usr/lib/qt3/lib/libqt-mt.so.3 #30 0x402b4a70 in QSocketNotifier::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0x40231d5f in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #32 0x40233a83 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0x40225e76 in QEventLoop::activateSocketNotifiers () from /usr/lib/qt3/lib/libqt-mt.so.3 #34 0x401df242 in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #35 0x40249e51 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #36 0x40249c96 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #37 0x4023394f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #38 0x082524a0 in lyx_gui::start ([EMAIL PROTECTED], [EMAIL PROTECTED]) at lyx_gui.C:265 #39 0x081051f0 in LyX::priv_exec (this=0x8426ce8, [EMAIL PROTECTED], argv=0xbfffe8f4) at lyx_main.C:28 6 #40 0x08104931 in LyX::exec ([EMAIL PROTECTED], argv=0xbfffe8f4) at lyx_main.C:143 #41 0x08064437 in main (argc=1, argv=0xbfffe8f4) at main.C:47 It seems
Re: bug 1656
Stephan Witt wrote: Jean-Marc Lasgouttes wrote: Last weekend I did some further investigation. 1. Checking the behaviour of kwrite it opens a question box to save the changes when it gets the focus... Hm... when it is iconized or on another desktop it doesn't ask? Really strange. 2. Checking the patched lyx [...] It seems to be another problem with processEvents... I forgot to say it doesn't differ from unpatched lyx! Stephan --
Re: Mysterious addition of dots after citation
Bo Peng wrote: Compress with gzip, lyx 1.4.0 reads and writes compressed files. FWIW lyx2lyx already does that, even in 1.3.x. We don't advertise this as it is a 1.4.x feature but it already there. :-) Then, problem solved, right? Is there a way to make compressed .lyx default R/W format? Few people will need to edit .lyx file directly. If one does, s/he will know how to decompress a lyx file. I would vote for a configureable option (with GUI too?). The good old text file is easier to handle when you want to CVS your .lyx files. Stephan
Re: 'find' portability problem (was Re: LyX and OS X)
Jean-Marc Lasgouttes wrote: Nirmal == Nirmal Govind [EMAIL PROTECTED] writes: Hello lyx-devel, I continue this private discussion with Nirmal and Bennett here, since I am sure somebody will come up with the one true find syntax we need. The problem is that compilation hangs in po, and the reason is the following find invokation in po/Makefile.in.in: find src -regex .*\\.\\(C\\|c\\|h\\|C\\.in\\) -print Nirmal My bad.. the correct syntax should be: Nirmal find src \( -regex .*\\.\\C -or -regex .*\\.\\c -or -regex Nirmal .*\\.\\h -or -regex .*\\C\\.in \) -print Nirmal This works well and from man find on OS X, there does not seem Nirmal to be support for the | syntax for the logical OR (I'm pasting Nirmal some of the relevant parts of man find below).. I took a look at the find man page which reads: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/find.1.html] -regex pattern True if the whole path of the file matches pattern using regular expression. To match a file named ``./foo/xyzzy'', you can use the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not ``xyzzy'' or ``/foo/''. This is OK. However, there is also this option about the type of regular expressions: -E Interpret regular expressions followed by -regex and -iregex options as extended (modern) regular expressions rather than basic regular expressions (BRE's). The re_format(7) manual page fully describes both formats. So, what is a basic RE according to apple? The man page re_format says: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/re_format.7.html] Obsolete (``basic'') regular expressions differ in several respects. `|' is an ordinary character and there is no equivalent for its functionality. [...] So it seems that Darwin's find cannot handle our find regular expression, because BRE cannot do `or'. OTOH, it seems that we cannot use EREs with GNU find. Except for the .C.in case, it seems that we could use find src -name '*.[Cch]' -print (this is basically what we did in 1.3.x) So what is the truly portable way to do a ``or'' in find-world? Shall we use \( foo -or bar \)? Hi Jean-Marc, as far as I know I would do it like that: find path-name-list \( -name foo -o -name bar \) -print Stephan
Re: 'find' portability problem
Jean-Marc Lasgouttes wrote: Bennett == Bennett Helm [EMAIL PROTECTED] writes: Bennett On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan as far as I know I would do it like that: Stephan find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. Bennett It works for me. Hello JMarc, hello Bennett, if you call me a nit-picker... maybe, you're right. But: I wrote find path-name-list \( -name foo -o -name bar \) -print. The command find src \( -name '*.[Cch]' -or -name '*.C.in' \) is a (unneeded) GNU-ism. The standard Unix find doesn't like the -or. You have to use the -o here in case it should stay portable. Greets, Stephan
Re: 'find' portability problem
Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan if you call me a nit-picker... maybe, you're right. But: Stephan I wrote find path-name-list \( -name foo -o -name bar \) Stephan -print. Stephan The command find src \( -name '*.[Cch]' -or -name '*.C.in' Stephan \) is a (unneeded) GNU-ism. The standard Unix find doesn't Stephan like the -or. You have to use the -o here in case it Stephan should stay portable. No, you are not a nitpicker , since the problem we have right now is related to portability. So we shall use -o. Thanks. Some people get nervous when I tell them such things. :) What about -print? Is it really necessary? I think so. The find command on Solaris 2.7 prints all files otherwise. I'm not sure if this makes sense in any case, but it is like that. Old BSD find did nothing when no action like -print or -ls was missing. I would use -print. It's save and documented. Greets, Stephan
Re: Latest CVS compile error on Solaris
Lars Gullik Bjønnes wrote:
Kayvan A. Sylvan [EMAIL PROTECTED] writes:
| ../../../lyx/src/client/client.C: In function `int
|support::socktools::connect(const std::string)':
| ../../../lyx/src/client/client.C:118: `SUN_LEN' undeclared (first use this
|function)
| ../../../lyx/src/client/client.C:118: (Each undeclared identifier is
| reported
So what does un.h say that SUN_LEN is called on this box?
This is the contents of un.h (/usr/include/sys/un.h) on my box:
/* Structure describing the address of an AF_LOCAL (aka AF_UNIX) socket. */
struct sockaddr_un
{
__SOCKADDR_COMMON (sun_);
char sun_path[108]; /* Path name. */
};
#ifdef __USE_MISC
# include string.h/* For prototype of `strlen'. */
/* Evaluate to actual length of the `sockaddr_un' structure. */
# define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)-sun_path)\
+ strlen ((ptr)-sun_path))
#endif
What does it look like on your box?
The complete un.h fills one page only... (for Solaris 2.7)
#ifndef _SYS_UN_H
#define _SYS_UN_H
#pragma ident @(#)un.h 1.9 96/07/12 SMI /* UCB 7.1 6/4/86 */
#ifdef __cplusplus
extern C {
#endif
#ifndef _SA_FAMILY_T
#define _SA_FAMILY_T
typedef unsigned short sa_family_t;
#endif
/*
* Definitions for UNIX IPC domain.
*/
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
charsun_path[108]; /* path name (gag) */
};
#ifdef _KERNEL
int unp_discard();
#endif
#ifdef __cplusplus
}
#endif
#endif /* _SYS_UN_H */
Re: [preliminary patch] moving XFig files
Andreas Vox wrote: Angus Leeming [EMAIL PROTECTED] writes: what about [ `dirname $1` -ef `dirname $2` ] ? test -e FOO is a bash extension. Also, dirname does nothing more than strip everything after the final '/' character. /foo/bar/../baz.cpp and /foo/baz.cpp will appear to be in different directories. Correct for dirname, but -ef as well as cd+pwd will use the true directory. Also I found '-ef' documented in the man page for ksh (SunOS 5.8) and BSD test, so I think it should be available on most platforms. Hi Andreas, yes, on Solaris it's available for ksh - but not for sh. (The standard shell for scripting and used by make.) So it's not true to say it's available for all (or most) platforms. With kind regards, Stephan
Re: announce lyx-1.1.6pre2; Preferences menu
Jean-Marc Lasgouttes wrote: "Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus I've just discovered a small inconsistency here. I wasn't Angus allowing the user to input anything other than an unsigned int Angus for the screen font sizes. Since the defaults (on display) are: Angus \screen_font_sizes 5.0 7.0 8.0 9.0 10.0 12.0 14.4 17.28 20.74 Angus 24.88 Angus Then that was probably a little irritating. Angus I'm thinking of a new fl_unsigned_float_filter. For the time Angus being it's very simple. It will accept a ".", but should it Angus also allow users to input a "," if they're "foreign"? Or is Angus this exactly what LC_NUMERIC=C forbids? Do not accept "," in floats. Concerning the filter, we have a isStrDbl in lstring.C which may be useful. I think it's a better solution to read/write from external file with non-locale functions to avoid the format problems when exchange files with other users or other program versions. But the user interface should honor the locale environment of the current user session. Whilst the read/write of the external representation isn't fixed, the user interface is bound to accepting "." only. But that's automatic behaviour with LC_NUMERIC=C. But I'm no C++ programmer, I don't know the correct call-interface to achieve that. With standard C I whould use: - [sf]printf to show a numeric value via user interface - a self-written function to save that number to external file - strtol/strtod to read a numeric user inputvalue - and a self-written function to read from external file The use of setlocale() is a possiblity for the self-written functions, but this isn't multi thread safe and you have to save and restore the current value. Regards, Stephan PS. Sorry for sending this. I'm reading this list, but haven't any time to learn coding with C++ and contribute code. [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: LyX still does not compile (workaround found, but bug real)
Jean-Marc Lasgouttes wrote: "Duncan" == Duncan Simpson [EMAIL PROTECTED] writes: Duncan so X11 has grabbed Object too... Yes, that's the problem. We have a SigC::Object that is brought into global space (because some compilers do not have namespaces). However, Object is only defined for Xt and xforms does not rely on Xt. Duncan As for people not using xforms 0.88 then start dreaming now. My xforms 0.88.1 forms.h does not have this behaviour. I see two possibilities: - people use a lyx rpm. Then they do not need to recompile and all is well. - people want to recompile. The they are smart enough to upgrade their xforms rpm. Duncan Even if that was not true as soon as anyone does a motif Duncan port the duplicate name gets them again, Arghh! LyX was already ported _from_ Motif, so I hope it will not go back. More seriously, when this happens, we will probably rely on namespaces anyway. And as Lars pointed out, naming a struct Object in a library is _bad_. Maybe, but what's with the library SigC? Isn't it bad too? The lib Xt is as old as I'm a programmer (10 years) and the "problem" is there since these days... The view of such things may shifted, but one concern of the X11 team is compatibility with previous versions. So they're right to leave this as it is. I don't believe that *all* possible LyX-GUI's can rely on avoiding the use of the Intrinsics. And the use of Motif is industrial standard and the only problem is the licensing --- solved with OpenMotif now/soon. A possible workaround(?) #define Object XtObject #include X11/Intrinsics.h #undef Object should replace the line #include X11/Intrinsics.h or analogous: define Object XtObject #include forms.h #undef Object Regards, Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: HPUX 10.20, gcc and vsnprintf
Bruce Foster wrote: Here is a lyx-1.1.6pre3 compilation failure under HPUX 10.20 using gcc-2.95.2: /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -I/opt/local/include -D_HPUX_SOURCE -fno-rtti -fno-exceptions -W -Wall -c fmt.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -I/opt/local/include -D_HPUX_SOURCE -fno-rtti -fno-exceptions -W -Wall -c fmt.C -o fmt.o fmt.C: In function `class string fmt(const char *, ...)': fmt.C:40: implicit declaration of function `int vsnprintf(...)' Note that configure finds (v)snprintf OK on my system. I've been able to configure and build lyx 1.1.5fix2 using the same software suite, so I'm not new to LyX. What's the best way to proceed? Maybe, the configure script tries to compile with the C-compiler and the function is inside a library and not listed in any header. So the check for vsnprintf succeeded but the C++-compiler failed because of the missing header file. Regards, Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: Sub-windows on top
Marcello Nuccio wrote: On Tue, Feb 06, 2001 at 05:52:31PM +1000, Allan Rae wrote: you get _nothing_ because we can't raise an iconified dialog. Mozilla does it. I have Gnome+Sawfish, but I think it's possible with any WM. This depends on the used toolkit. Yes, you can raise and iconify every dialog shell from the application if you have access to the appropriate Xlib/Xt functions with the needed parameters. (Mozilla does this, I guess.) For example with the given shell widget: XtVaSetValues(shell, XtNiconic, False, NULL); XMapWindow(XtDisplay(shell), XtWindow(shell)); or XtVaSetValues(shell, XtNiconic, True, NULL); I don't know if XForms gives the programmer access to these shell widget or gives the needed functions. If you set your dialog to transient these all is builtin. Regards, Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: [dat96gln@student3.lu.se] LyX Feedback
Lars Gullik Bjønnes wrote: Do anyone compile Lyx on a sun system? SunOS or Solaris? I'd be grateful to accept binary distributions for these. Lgb --- Start of forwarded message --- Date: Thu, 18 Feb 1999 14:02:51 +0100 Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: LyX Feedback Reply-to: [EMAIL PROTECTED] Hello. I have been waiting for the precompiled SUN 1.0.0 version of LyX for some time... when will it appear in the /bin/1.0.0 directory at ftp.lyx.org ? Kind regards, from a LyX user who want to be able to run it on his SUN machine... --- End of forwarded message --- Yes I do. Currently I compile LyX on Solaris 2.5.1 using Suns CC (SC4.0 C++ 4.1). With Solaris there had to be a native package solution too. The pure binary does not help, the generous person has to make a package with the runtime-files too, what about runtime configuration, and so on... I guess it is real work... What is the situation with libforms.so? Can I distribute it bundled? I don't want to link it statically. The same with X11, I'm using my own X11R6.3, have to test with Suns X11. BTW, I really don't know what SUN 1.0.0 is. Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: lyx-1.0.1pre2 is out
Lars Gullik Bjønnes wrote: Available at ftp.lyx.org, ftp.devel.lyx.org. Next pre scheduled in a week. 1.0.1 scheduled 1. Mar. Lgb Thanks. I tried to compile it on Solaris. It seems to compile and run after correcting one thing my compiler doesn't accept: In file src/math_root.C line 25 I had to change MathRootInset::MathRootInset(short st=LM_ST_TEXT): MathSqrtInset(st) to MathRootInset::MathRootInset(short st): MathSqrtInset(st) The error message was: "math_root.C", line 25: Error: A previously specified default argument value cannot be changed. Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: docs for non-english
Lars Gullik Bjønnes wrote:
Daniel Naber writes:
DN Stephan Witt wrote:
+ uncomment the line \font_encoding T1 in your lyxrc + change in
Layout-Document - Sprache (Language) = german - Kodierung (?)
= latin1
You shouldn't need to change the preamble for this.
DN I see. IMHO, we should add to splash.lyx, how much you can
DN configure using lyxrc. Whenever something doesn't work, just
DN change lyxrc. The font-encoding in lyxrc could perhaps need a
DN sentence with the word "umlaut" in it, so lazy people like can
DN find it with a simple search...
Also if you have the ec fonts (T1) installed, it is used by default by
lyx. so you should not need to edit the lyxrc at all then.
I read this in the lyxrc too, but I cannot find the code for that.
My experience is that uncommenting \font_encoding yields better results.
If not uncommented, there is no \usepackage[T1]{fontenc} in my
exported latex file, but if I add this line it works and it works
better.
Could you give me some hint about the ec-font test, please?
Maybe, there is a mistake in my configuration. I don't understand
this.
Stephan
---
[EMAIL PROTECTED] | beusen unternehmensgruppe senkel
fon: +49 30 549932-62 | Landsberger Allee 392
fax: +49 30 549932-29 | 12681 Berlin, Germany
---
Bug Report, Compiling on Solaris/CC
ache::ID. "filedlg.C", line 144: Warning: ID hides GroupCache::ID. "filedlg.C", line 160: Warning: pszName hides GroupCache::pszName. "filedlg.C", line 160: Warning: ID hides GroupCache::ID. "filedlg.C", line 160: Warning: pRoot hides GroupCache::pRoot. "filedlg.C", line 185: Warning: ID hides GroupCache::ID. 10 Warning(s) detected. CC -c -g -I. -I. -I../images -I/usr/X11R6.3/include BufferView.C "BufferView.C", line 1085: Warning: work_area_width hides BufferView::work_area_width. 1 Warning(s) detected. CC -c -g -I. -I. -I../images -I/usr/X11R6.3/include LaTeX.C "LaTeX.C", line 441: Warning: file hides LaTeX::file. "LaTeX.C", line 459: Warning: file hides LaTeX::file. 2 Warning(s) detected. CC -c -g -I. -I. -I../images -I/usr/X11R6.3/include Chktex.C "Chktex.C", line 86: Warning: file hides Chktex::file. 1 Warning(s) detected. CC -c -g -I. -I. -I../images -I/usr/X11R6.3/include ImportLaTeX.C "ImportLaTeX.C", line 41: Warning: file hides ImportLaTeX::file. 1 Warning(s) detected. After the mentioned changes, the created lyx is ok and running. We're (our Unix-group) using it for documentation purposes. It's a great help to have such tool and we like it. Thanks for your good work. Have a good day and a happy new year. Stephan Witt --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: Bug Report, Compiling on Solaris/CC
Jean-Marc Lasgouttes wrote:
"Stephan" == Stephan Witt [EMAIL PROTECTED] writes:
Stephan Hi, I've downloaded the tar file lyx-1.0.0pre6.tar.gz from
Stephan la1ad.uio.no at Tue Jan 5 13:55:17 1999
Hi,
Stephan 1. The file INSTALL suggests the usability of XForms Version
Stephan 0.81 (I have it). The problem is in file lines 139 and
Stephan 140. There is no prototype (and probably no code) in this
Stephan version for fl_add_labelframe.
There is a typo above. The file of interest is src/layout_forms.C.
Sorry.
% grep -n fl_add_labelframe src/*.C
src/layout_forms.C:139:// obj =
fl_add_labelframe(FL_ENGRAVED_FRAME,10,220,280,45,_("These are never
toggled"));
src/layout_forms.C:140:// obj =
fl_add_labelframe(FL_ENGRAVED_FRAME,10,280,280,45,_("These are allways
toggled"));
I do not have xforms 0.81 here. Could you tell me whether there is
something about frames in forms.h?
% grep -n frame /usr/include/forms.h
1033:extern void fl_drw_frame(int, FL_Coord, FL_Coord, FL_Coord,
FL_Coord,
2018: * $Id: frame.h,v 0.11 1995/04/01 00:39:31 zhao Exp $
2025:/* types of frames */
2039:extern FL_OBJECT *fl_create_frame(int, FL_Coord, FL_Coord,
2042:extern FL_OBJECT *fl_add_frame(int,FL_Coord,FL_Coord,
Stephan I tried to download a newer
Stephan library version but can't (because of missing PTR-RR, a
Stephan shame, I know) and removed this two lines to continue.
What is a PTR-RR?
This is a problem of system administration. My host has a valid
IP-Address
assigned but the FTP-server cannot resolve this IP-Address to a valid
official hostname. The FTP-server ftp.cs.ruu.nl doesn't let me loggin
until I fix this or use another official host as "proxy".
The directory ftp://ftp.lyx.org/pub/xforms is empty.
The host ftp://einstein.phys.uwm.edu/pub/xforms has no anon-ftp.
The url http://bloch.phys.uwm.edu/xforms doesn't exist.
The best solution is to remove the string 0.81 from INSTALL and
correct the URL for XForms with http://bragg.phys.uwm.edu/xforms.
Stephan 2. The file src/buffer.C holds a bug. In line 952 there is a
Stephan call of LString::empty but the parens are missing. My
Stephan compiler said:
This one has already been fixed.
Stephan "buffer.C", line 211: Warning: filename hides
Stephan Buffer::filename.
I've seen some of these, but I'm not sure what they mean. It seems
that it is safe to somply ignore them.
I'm not a C++ expert, but I think it means you have declared a local
variable "filename" and this variable hides something named "filename"
declared in your current class namespace. You can assign it with
filename := expression ;
and you assign the local instance on stack. It's ok if you expect this
and it's not ok if you intentionally like to assign the class variable.
(May be, you look at the code with the local variable and see the
assignment,
but you overlook the local declaration, expect the class variable be
assigned
and waste a long time to explore the reason for this behaviour.)
A simple solution to make the compiler silent and the things clear
is to rename the offending local variables.
Thanks,
---
[EMAIL PROTECTED] | beusen unternehmensgruppe senkel
fon: +49 30 549932-62 | Landsberger Allee 392
fax: +49 30 549932-29 | 12681 Berlin, Germany
---
Re: Print dialogue
Jean-Marc Lasgouttes wrote: "Reuben" == Reuben Thomas [EMAIL PROTECTED] writes: Reuben I'm sure many people have made similar points before, but just Reuben to make sure: Reuben 1. It's most annoying not being able to print just a selection Reuben of pages. There have been a patch for that some time ago, but it was against an older version of LyX and could not apply. I asked the author of the patch whether he cold re-do it for the newest version, but got no answer. I think I still have it around if someone is interested. Note that you can enter dvips option in the 'printer' input filed, I think. Something like 'foo -pp2-4' should produce 'dvips -Pfoo -pp2-4' and send pages 2 to 4 to printer foo. I found it works only with \adapt_printer_output true in the lyxrc. And this passes -pp2-4 to lp too, if you set \print_spool_command "lp -o nobanner" for example. So, I think the patch would be something better (and foolproof). Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Re: Compiling under Solaris 7 (x86)
Lars Gullik Bjønnes wrote: Apostolos Syropoulos writes: AS LIBS = $(LYX_LIBS) -lSM -lICE -liberty -ldl -lc -lm -lforms AS -L/usr/openwin/lib -R/usr/openwin/lib -lX -lX11 -lXpm -lsocket AS -lnsl What libraries were used by LyX? Lgb AFAIK there is a "real" X11.R6 shipped with Solaris 7 and derfor the libX11 needs the libraries libSM.so and libICE.so. The "real" means I don't know what the Sun developers did with the code to support Display Postscript and so on. Normally they sell a modified version of X11 with some potentially headache for programmers. But I can't understand why the configure didn't detect the X11 library list completely. Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
Scientific lyxlength?
Dear LyX developers, today I managed to configure and compile latest 1.3.x lyx from CVS. While testing the resulting binary I detected a minor but serious problem: the lyxlength numbers will be emitted to tex in scientific format when for example pt is the unit. So 140pt will be send to LaTeX as 1.4e+02pt and this breaks the LaTeX-compile step. I don't know how to fix this correctly but I'll attach my own solution... Regards, Stephan Index: lyxlength.C === RCS file: /cvs/lyx/lyx-devel/src/lyxlength.C,v retrieving revision 1.26.2.3 diff -u -p -r1.26.2.3 lyxlength.C --- lyxlength.C 2004/12/07 10:48:37 1.26.2.3 +++ lyxlength.C 2004/12/20 14:21:49 @@ -78,7 +78,7 @@ string const LyXLength::asLatexString() buffer setprecision(2) val_/100.0 \\textheight; break; default: - buffer setprecision(2) val_ unit_name[unit_]; + buffer setprecision(2) setiosflags (std::ios_base::fixed) val_ unit_name[unit_]; break; } return STRCONV(buffer.str());
Re: Scientific lyxlength?
Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan Dear LyX developers, today I managed to configure and compile Stephan latest 1.3.x lyx from CVS. While testing the resulting binary Stephan I detected a minor but serious problem: the lyxlength numbers Stephan will be emitted to tex in scientific format when for example Stephan pt is the unit. So 140pt will be send to LaTeX as 1.4e+02pt Stephan and this breaks the LaTeX-compile step. Hello, Could you send an example file? I cannot reproduce that. What version of gcc are you using? Could it be related to locale settings? I hate these things... I'm sure this is designed to ruin my xmas :) Sorry for that, that's the last what I wanted to achieve... Ok, the config.log contains: uname -m = i686 uname -r = 2.4.19-4GB uname -s = Linux uname -v = #1 Fri Sep 13 13:14:56 UTC 2002 configure:2232: checking for gcc configure:2248: found /usr/local/bin/gcc configure:2258: result: gcc configure:2502: checking for C compiler version configure:2505: gcc --version /dev/null 5 gcc (GCC) 3.2.3 Thread model: posix gcc version 3.2.3 % strings /usr/local/lib/libstdc++.so.5|grep GLIBCPP_3 GLIBCPP_3.2 GLIBCPP_3.2.1 GLIBCPP_3.2.2 % locale [EMAIL PROTECTED] LC_CTYPE=[EMAIL PROTECTED] LC_NUMERIC=[EMAIL PROTECTED] LC_TIME=[EMAIL PROTECTED] LC_COLLATE=POSIX LC_MONETARY=[EMAIL PROTECTED] LC_MESSAGES=[EMAIL PROTECTED] LC_PAPER=[EMAIL PROTECTED] LC_NAME=[EMAIL PROTECTED] LC_ADDRESS=[EMAIL PROTECTED] LC_TELEPHONE=[EMAIL PROTECTED] LC_MEASUREMENT=[EMAIL PROTECTED] LC_IDENTIFICATION=[EMAIL PROTECTED] LC_ALL= ... and last but not least, the attached example file. Thank you for taking this issue. Regards, Stephan #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass article \begin_preamble \end_preamble \language german \inputencoding latin1 \fontscheme pslatex \graphics default \float_placement htp \paperfontsize default \spacing single \papersize a4paper \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation skip \defskip medskip \quotes_language french \quotes_times 2 \papercolumns 1 \papersides 2 \paperpagestyle fancy \layout Standard \begin_inset Graphics filename bfs_logo_new.gif display none width 140pt height 45pt rotateOrigin leftBaseline \end_inset \the_end
Re: Scientific lyxlength?
Stephan Witt wrote: Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: [ snip ] ... and last but not least, the attached example file. Thank you for taking this issue. And now the included graphics... (I forgot it). Regards, Stephan inline: bfs_logo_new.gif
Re: The LyX licence
Angus Leeming wrote: I asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt: The following people hereby grant permission to licence their contributions to LyX under the Gnu General Public Licence, version 2 or later. Yes, of course. I grant permission to licence any and all contributions I made to LyX under the Gnu General Public Licence, version 2 or later. Regards, Stephan
Patch for 1.3.X: vc-backend file quoting+CVS::checkOut
Dear LyX-Developers,
recently I started to check BRANCH_1_3_X for productive work.
I'm very pleased with the features and stability of it.
We're using CVS at our site for managing revision control
of our documents. So I had a look in src/vc-backend.C to
see if I can make a working implementation of CVS::checkOut().
The attached patch contains two things:
1) the mentioned functionality of CVS checkOut
2) a change in filename quoting
The files will be quoted now with help of QuoteName()
for improved filename stability.
Now I propose to include the patch in the lyx repository.
I had a question nevertheless about the handling of the
message strings: I guess they should be quoted like filenames,
but I don't know if the would be acceptable.
Regards,
Stephan
Index: src/vc-backend.C
===
RCS file: /cvs/lyx/lyx-devel/src/vc-backend.C,v
retrieving revision 1.36.2.3
diff -u -p -r1.36.2.3 vc-backend.C
--- src/vc-backend.C2005/01/05 15:53:17 1.36.2.3
+++ src/vc-backend.C2005/03/04 09:08:36
@@ -94,8 +94,8 @@ string const RCS::find_file(string const
void RCS::retrieve(string const file)
{
lyxerr[Debug::LYXVC] LyXVC::RCS: retrieve.\n\t file endl;
- VCS::doVCCommand(co -q -r \
-+ file + '',
+ VCS::doVCCommand(co -q -r
++ QuoteName(file),
string());
}
@@ -168,9 +168,8 @@ void RCS::registrer(string const msg)
{
string cmd = ci -q -u -i -t-\;
cmd += msg;
- cmd += \ \;
- cmd += OnlyFilename(owner_-fileName());
- cmd += '';
+ cmd += \ ;
+ cmd += QuoteName(OnlyFilename(owner_-fileName()));
doVCCommand(cmd, owner_-filePath());
reload();
}
@@ -178,8 +177,8 @@ void RCS::registrer(string const msg)
void RCS::checkIn(string const msg)
{
- doVCCommand(ci -q -u -m\ + msg + \ \
- + OnlyFilename(owner_-fileName()) + '',
+ doVCCommand(ci -q -u -m\ + msg + \
+ + QuoteName(OnlyFilename(owner_-fileName())),
owner_-filePath());
reload();
}
@@ -188,8 +187,8 @@ void RCS::checkIn(string const msg)
void RCS::checkOut()
{
owner_-markClean();
- doVCCommand(co -q -l \
- + OnlyFilename(owner_-fileName()) + '',
+ doVCCommand(co -q -l
+ + QuoteName(OnlyFilename(owner_-fileName())),
owner_-filePath());
reload();
}
@@ -197,8 +196,8 @@ void RCS::checkOut()
void RCS::revert()
{
- doVCCommand(co -f -u + version() + \
- + OnlyFilename(owner_-fileName()) + '',
+ doVCCommand(co -f -u + version() +
+ + QuoteName(OnlyFilename(owner_-fileName())),
owner_-filePath());
// We ignore changes and just reload!
owner_-markClean();
@@ -209,16 +208,16 @@ void RCS::revert()
void RCS::undoLast()
{
lyxerr[Debug::LYXVC] LyXVC: undoLast endl;
- doVCCommand(rcs -o + version() + \
- + OnlyFilename(owner_-fileName()) + '',
+ doVCCommand(rcs -o + version() +
+ + QuoteName(OnlyFilename(owner_-fileName())),
owner_-filePath());
}
void RCS::getLog(string const tmpf)
{
- doVCCommand(rlog \
- + OnlyFilename(owner_-fileName()) + \
+ doVCCommand(rlog
+ + QuoteName(OnlyFilename(owner_-fileName())) +
+ tmpf, owner_-filePath());
}
@@ -308,8 +307,8 @@ void CVS::scanMaster()
void CVS::registrer(string const msg)
{
- doVCCommand(cvs -q add -m \ + msg + \ \
- + OnlyFilename(owner_-fileName()) + '',
+ doVCCommand(cvs -q add -m \ + msg + \
+ + QuoteName(OnlyFilename(owner_-fileName())),
owner_-filePath());
reload();
}
@@ -317,8 +316,8 @@ void CVS::registrer(string const msg)
void CVS::checkIn(string const msg)
{
- doVCCommand(cvs -q commit -m \ + msg + \ \
- + OnlyFilename(owner_-fileName()) + '',
+ doVCCommand(cvs -q commit -m \ + msg + \
+ + QuoteName(OnlyFilename(owner_-fileName())),
owner_-filePath());
reload();
}
@@ -327,7 +326,10 @@ void CVS::checkIn(string const msg)
void CVS::checkOut()
{
// cvs update or perhaps for cvs this should be a noop
- lyxerr Sorry not implemented. endl;
+ doVCCommand(cvs -q edit
+ + QuoteName(OnlyFilename(owner_-fileName())),
+ owner_-filePath());
+ reload();
}
@@ -335,9 +337,9 @@ void CVS::revert()
{
// Reverts to the version in CVS repository and
// gets the updated version from the repository.
- string const fil = OnlyFilename(owner_-fileName());
+ string const fil = QuoteName(OnlyFilename(owner_-fileName()));
-
Re: Patch for 1.3.X: vc-backend file quoting+CVS::checkOut
Lars Gullik Bjønnes wrote:
Stephan Witt [EMAIL PROTECTED] writes:
| Dear LyX-Developers,
| recently I started to check BRANCH_1_3_X for productive work.
| I'm very pleased with the features and stability of it.
| We're using CVS at our site for managing revision control
| of our documents. So I had a look in src/vc-backend.C to
| see if I can make a working implementation of CVS::checkOut().
| The attached patch contains two things:
| 1) the mentioned functionality of CVS checkOut
I am not sure this is a good idea.
But, this is the only sensible operation for the menu item
Versionskontrolle = Zur Bearbeitung auschecken.
Perhaps the association of that menu item with CVS::checkOut()
is misleading. It should be renamed to CVS::edit() perhaps.
But that was not my primary goal.
Do you actually use cvs edit when
editing a file?
Yes.
Why not cvs checkout btw?
I cannot see how this should work. I want to make a writable copy of a file
inside a checkout I already did before.
We usually do a read-only checkout to be
1) sure not to modify a file by accident
2) be able to see who is editing a file with cvs editors
And how should I checkout a file with LyX?
The file is not present at this time. So it is not open and the
menu item Versionskontrolle is disabled.
And do you actually use it?
Yes.
| 2) a change in filename quoting
Does this fix a problem?
Yes. If one has a filename like 'file$patch1.lyx' the vc-backend fails
to process this one. It makes a system call like 'cvs log file$patch1.lyx'
for example. The shell tries to expand the environment variable patch1 and
replaces this with nothing. So you get 'cvs log file.lyx' after all.
The patched version uses QuoteName() and produces
cvs log 'file$patch1.lyx'
when the OS is Unix.
Even in 1.4 I would be wary of changing this at this stage, unless it
fixes a real experienced problem.
| @@ -327,7 +326,10 @@ void CVS::checkIn(string const msg)
| void CVS::checkOut()
| {
| // cvs update or perhaps for cvs this should be a noop
| - lyxerr Sorry not implemented. endl;
| + doVCCommand(cvs -q edit
| + + QuoteName(OnlyFilename(owner_-fileName())),
| + owner_-filePath());
| + reload();
| }
Regards,
Stephan
Re: Patch for 1.3.X: vc-backend file quoting+CVS::checkOut
Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | | Yes. If one has a filename like 'file$patch1.lyx' the vc-backend fails | | to process this one. It makes a system call like 'cvs log file$patch1.lyx' | | for example. The shell tries to expand the environment variable patch1 and | | replaces this with nothing. So you get 'cvs log file.lyx' after all. Note that I didn't just mean if it is possible to construct files that gives problems, but also if you actually have problems and have experienced them in real life. Sorry, I cannot follow you. It is a real problem in the code. And I would say, since QuoteName() came into existance it should be used because it is save and it is OS-independant. The question of the occurance in real live has to answered with yes or no. Yes, I saw a filename with an dollar-sign in it created by ordinary users already and no it was no lyx file. So, you may choose the answer yourself :) The case of the dollar-signed file was placed in an CVS-Repository by an innocent Windows-User and we had a funny time with it. Regards, Stephan
Re: Patch for 1.3.X: vc-backend file quoting+CVS::checkOut
Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | | Yes. If one has a filename like 'file$patch1.lyx' the vc-backend fails | | to process this one. It makes a system call like 'cvs log file$patch1.lyx' | | for example. The shell tries to expand the environment variable patch1 and | | replaces this with nothing. So you get 'cvs log file.lyx' after all. Note that I didn't just mean if it is possible to construct files that gives problems, but also if you actually have problems and have experienced them in real life. May I kindly ask for the result of our discussion? I answered all of your questions and now I cannot see how to proceed. My original question was the wish to add the CVS checkOut functionality to the code base of LyX. Of course it may be debateable if one should do this for the 1.3.X branch. And it may be improved by a check of the writeable state of the file checked out. With kind regards, Stephan
Re: Patch for 1.3.X: vc-backend file quoting+CVS::checkOut
Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| Lars | May I kindly ask for the result of our discussion? | I
| Lars answered all of your questions and now I cannot see how to
| Lars proceed.
| Lars For 1.3. J-M is calling the shots.
| I propose to commit the QuoteName changes to 1.3.x and 1.4.0cvs, since
| they seem obvious enough.
| Lars, OK?
ok
Thank you all.
Regarding the cvs edit subcommand:
I'm using readonly checkouts with the global option
-r (readonly), resp. an entry cvs -rq in my $HOME/.cvsrc.
So every file of my checkouts is readonly at the beginning.
If I want to edit it I have to be explicit and cannot do this
by accident. I can use a chmod or even better cvs edit.
So I added a mapping of function key F2 to $HOME/.exrc
and may turn the readonly checkout with a key press to an
writable one. Another benefit of using cvs edit is the
ability to tell if someone is working in parallel or has not
finished her modifications yet (cvs editors).
IMHO the mapping of CVS::checkOut to cvs edit makes sense
because of the logic of LFUN_VC_CHECKOUT too:
case LFUN_VC_CHECKOUT:
{
if (owner-buffer()-lyxvc.inUse()// file is checked out already
owner-buffer()-isReadonly()) // file is readonly
owner-buffer()-lyxvc.checkOut();
}
break;
Maybe the terminus CHECKOUT is a bit misnamed here.
Stephan
Re: LyX meeting in Paris. When?
Jean-Marc Lasgouttes wrote: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I have a list of dates for the LyX meeting in Paris. Jean-Marc Unfortunately it is a bit short, but we'll see if they suit Jean-Marc enough people to be useful. So it sound the dates are not too bad. Let's see who answered already: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 0 Asger 0 0 3 5 Of course, I made up the numbers :) Feel free to correct me. Concerning other dates, it will be more difficult for me, especially since only school stops around Jul 12. And later in August, I will have difficulties to avoid family vacations... Who else is wanting to come? All answers are appreciated, even ``I can't tell you yet'' or ``I'd hate to be there''. I can't tell you yet for sure, but it looks like it happens to me to stay in Paris appr. from 8th of July til 20th of July. I'll have a trip for these days with my family and I'm interested in visiting the LyX meeting. And as always, everybody is welcome. If my appartment turns out to be too small, I have both a plan B and a plan C. So I would say you may add my name for Jul 16 ranked 4 and ranked 0 for the rest of time. Of course my name shouldn't weight to much on this list. I cannot contribute any hardware but I don't need a bed for the night. And I'm not a beer drinker :) Greetings, Stephan
Portability problem with lib/configure srcipt on Solaris Watchdog: Virus checked
I've found a porting issue on Solaris.
The shell script lib/configure is GNU-specific. There is
1. a badly placed ! operator for test of file existance and
2. an problem with grep (extended expression syntax)
These problems are fixed for the 1.3.x Branch with the
attached patch...
Hope it's of any help and acceptable.
Greetings,
Stephan
Index: configure.m4
===
RCS file: /cvs/lyx/lyx-devel/lib/configure.m4,v
retrieving revision 1.60.2.17
diff -u -p -r1.60.2.17 configure.m4
--- configure.m42005/03/25 15:35:52 1.60.2.17
+++ configure.m42005/04/20 09:51:07
@@ -431,7 +431,7 @@ changequote(,)dnl
# 5: if the macro did not have an optional argument, provide one
#(equal to the class name)
# 6: remove brackets and replace with correctly quoted entries
-grep '\\Declare\(LaTeX\|DocBook\|LinuxDoc\)Class' $file \
+egrep '\\Declare(LaTeX|DocBook|LinuxDoc)Class' $file \
| sed -e 's/^.*\DeclareLaTeXClass *\(.*\)/\1 false/' \
-e 's/^.*\DeclareDocBookClass *\(.*\)/\1
'$bool_docbook'/' \
-e 's/^.*\DeclareLinuxDocClass *\(.*\)/\1
'$bool_linuxdoc'/' \
@@ -447,7 +447,7 @@ changequote(,)dnl
else
MSG_RESULT(auto)
rm -f wrap_chkconfig.ltx chkconfig.vars chkconfig.classes chklayouts.tex
- if ! test -r chkconfig.ltx ; then
+ if test ! -r chkconfig.ltx ; then
ln -s ${srcdir}/chkconfig.ltx .
rmlink=true
fi
@@ -465,7 +465,7 @@ EOF
*) if test -r $file ; then
class=`echo $file | sed -e 's%^.*layouts/\(.*\)\.layout$%\1%'`
# Generate the proper TestDocClass command for this layout
- grep '\\Declare\(LaTeX\|DocBook\|LinuxDoc\)Class' $file \
+ egrep '\\Declare(LaTeX|DocBook|LinuxDoc)Class' $file \
| sed -e 's/^\# *\(.*\)$/\\TestDocClass{'${class}'}{\1}/'
fi ;;
esac
Re: Portability problem with lib/configure srcipt on Solaris Watchdog: Virus checked
Angus Leeming wrote: Stephan Witt wrote: Angus Leeming wrote: Stephan Witt wrote: Angus Leeming wrote: Jean-Marc Lasgouttes wrote: Angus Do you also want the stuff to address André's query? The test Angus would become: Why not. It scares me, but if you say it's portable, go ahead. But the poor man's version is good enough for me. Heck, now you've scared me! Why don't we give it to Stephan to try out on his Solaris machine? Do you want me to commit it to cvs or do you want Stephan to have a go first? That's no problem... I can do test a patch for you. Ok, here is lib/configure.m4 Stephan. snip Sorry for the delay, I'm a little busy right now. Hey, don't worry at all! Thanks for doing this. It is fun. I've to admit I'm working on *nix for years and I never mastered sed like you! Afterall I'll have to learn a bit of it. Now the results: snip details So, it should be all as expected :) Stephan Great. Then I'll commit these patches (attached for reference) to the 1.3.x and 1.4.x trees. Thanks, I'll leave the office now. snip Stephan
Re: Portability problem with lib/configure srcipt on Solaris Watchdog: Virus checked
Angus Leeming wrote: Jean-Marc Lasgouttes wrote: Angus Do you also want the stuff to address André's query? The test Angus would become: Why not. It scares me, but if you say it's portable, go ahead. But the poor man's version is good enough for me. Heck, now you've scared me! Why don't we give it to Stephan to try out on his Solaris machine? Do you want me to commit it to cvs or do you want Stephan to have a go first? That's no problem... I can do test a patch for you. Stephan
Re: Portability problem with lib/configure srcipt on Solaris
Angus Leeming wrote:
Stephan Witt wrote:
Angus Leeming wrote:
Jean-Marc Lasgouttes wrote:
Angus Do you also want the stuff to address André's query? The test
Angus would become:
Why not. It scares me, but if you say it's portable, go ahead. But the
poor man's version is good enough for me.
Heck, now you've scared me! Why don't we give it to Stephan to try out
on his Solaris machine? Do you want me to commit it to cvs or do you
want Stephan to have a go first?
That's no problem... I can do test a patch for you.
Ok, here is lib/configure.m4 Stephan. Just in case you don't have m4
installed, I attach also the configure that is generated from this .m4
file.
Before you test it out, could you modify your existing configure to print
out some data. See the lines in the attachment:
cp textclass.lst angus_textclass.lst
cp chklayouts.tex angus_chklayouts.tex
Edit your existing configure script to output, say, stephan_textclass.lst
and stephan_chklayouts.tex.
$ ./configure
$ ./configure --without-latex-config
Thereafter, build and run the new configure as:
$ m4 configure.m4 configure
$ ./configure
$ ./configure --without-latex-config
That should generate angus_chklayouts.tex and angus_textclass.lst
Comparing the new with the old, I find that there are (expected)
differences. Do you see something similar?
$ diff -u angus_orig_chklayouts.tex angus_chklayouts.tex
--- angus_orig_chklayouts.tex 2005-04-22 15:25:44.749542128 +
+++ angus_chklayouts.tex2005-04-22 15:27:45.594170952 +
@@ -1,7 +1,6 @@
\TestDocClass{IEEEtran}{\DeclareLaTeXClass{article (IEEEtran)}}
\TestDocClass{aa}{\DeclareLaTeXClass[aa]{article (AA)}}
\TestDocClass{aapaper}{\DeclareLaTeXClass[aa]{article (AA V4)}}
-\TestDocClass{aapaper}{\DeclareLaTeXClass[aa-old]{article (AA V4)}}
\TestDocClass{aastex}{\DeclareLaTeXClass[aastex]{article (AASTeX)}}
\TestDocClass{agums}{\DeclareLaTeXClass[aguplus,agums.sty]{article (AGU++)
manuscript}}
\TestDocClass{amsart-plain}{\DeclareLaTeXClass[amsart]{article (AMS,
unnumbered)}}
@@ -70,7 +69,6 @@
\TestDocClass{IEEEtran}{\DeclareLaTeXClass{article (IEEEtran)}}
\TestDocClass{aa}{\DeclareLaTeXClass[aa]{article (AA)}}
\TestDocClass{aapaper}{\DeclareLaTeXClass[aa]{article (AA V4)}}
-\TestDocClass{aapaper}{\DeclareLaTeXClass[aa-old]{article (AA V4)}}
\TestDocClass{aastex}{\DeclareLaTeXClass[aastex]{article (AASTeX)}}
\TestDocClass{agums}{\DeclareLaTeXClass[aguplus,agums.sty]{article (AGU++)
manuscript}}
\TestDocClass{amsart-plain}{\DeclareLaTeXClass[amsart]{article (AMS,
unnumbered
$ diff -u angus_orig_textclass.lst angus_textclass.lst
--- angus_orig_textclass.lst2005-04-22 15:26:23.144705176 +
+++ angus_textclass.lst 2005-04-22 15:27:53.605952976 +
@@ -6,7 +6,6 @@
IEEEtran IEEEtran article (IEEEtran) false
aa aa article (AA) false
aapaper aa article (AA V4) false
-aapaper aa-old article (AA V4) false
aastex aastex article (AASTeX) false
agums aguplus article (AGU++) manuscript false
amsart-plain amsart article (AMS, unnumbered) false
Sorry for the delay, I'm a little busy right now.
Ok, I created the original versions with my own patched scripts.
The current cvs scripts produced nothing...
Now the results:
$ diff -u stephan_chklayouts.tex angus_chklayouts.tex
--- stephan_chklayouts.tex 2005-04-22 18:12:59.0 +0200
+++ angus_chklayouts.tex2005-04-22 18:17:18.0 +0200
@@ -1,7 +1,6 @@
\TestDocClass{IEEEtran}{\DeclareLaTeXClass{article (IEEEtran)}}
\TestDocClass{aa}{\DeclareLaTeXClass[aa]{article (AA)}}
\TestDocClass{aapaper}{\DeclareLaTeXClass[aa]{article (AA V4)}}
-\TestDocClass{aapaper}{\DeclareLaTeXClass[aa-old]{article (AA V4)}}
\TestDocClass{aastex}{\DeclareLaTeXClass[aastex]{article (AASTeX)}}
\TestDocClass{agums}{\DeclareLaTeXClass[aguplus,agums.sty]{article (AGU++)
manuscript}}
\TestDocClass{amsart-plain}{\DeclareLaTeXClass[amsart]{article (AMS,
unnumbered)}}
@@ -70,7 +69,6 @@
\TestDocClass{IEEEtran}{\DeclareLaTeXClass{article (IEEEtran)}}
\TestDocClass{aa}{\DeclareLaTeXClass[aa]{article (AA)}}
\TestDocClass{aapaper}{\DeclareLaTeXClass[aa]{article (AA V4)}}
-\TestDocClass{aapaper}{\DeclareLaTeXClass[aa-old]{article (AA V4)}}
\TestDocClass{aastex}{\DeclareLaTeXClass[aastex]{article (AASTeX)}}
\TestDocClass{agums}{\DeclareLaTeXClass[aguplus,agums.sty]{article (AGU++)
manuscript}}
\TestDocClass{amsart-plain}{\DeclareLaTeXClass[amsart]{article (AMS,
unnumbered)}}
$ diff -u stephan_textclass.lst angus_textclass.lst
--- stephan_textclass.lst 2005-04-22 18:13:21.0 +0200
+++ angus_textclass.lst 2005-04-22 18:17:24.0 +0200
@@ -6,7 +6,6 @@
IEEEtran IEEEtran article (IEEEtran) false
aa aa article (AA) false
aapaper aa article (AA V4) false
-aapaper aa-old article (AA V4) false
aastex aastex article (AASTeX) false
agums aguplus article (AGU++) manuscript false
amsart-plain amsart article (AMS, unnumbered) false
Re: Performance oddity with X over ADSL
Angus Leeming wrote: Martin Vermeer wrote: On Thu, 2005-04-28 at 06:46, Martin Vermeer wrote: On Wed, Apr 27, 2005 at 10:57:25PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Is there an easy way to make the drawing more parsimonious? We used to have that and it was horribly complicated, and Andre cleaned it up, as I remember. Would it be worth pursuing in this case? Martin, does this patch fix the problem for you? It shoudl buffer the pixmap. -- Angus No Angus, it does not help. Character input remains syrupy precisely and only when there is a graphic within the display window. Are you sure you caught all the expensive drawing operations? Shouldn't you be using bitblt? I don't understand this stuff at all. This is double buffering, right? http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html I don't see why that will help in this case. You're complaining that we're going up and down the ADSL line to retrieve an image when we should be using the cached pixmap on your local machine. I fail to see what we're doing wrong. Obviously. I would guess the problem is the repaint operation itself. The Painter should not trigger the transfer of the pixmap at all when the user modifies the documents text content. Normally with an X event driven architecture you never draw to screen outside the XExposeEvent/XGraphicsExposeEvent events. You tell the X-Server the region which is updated by the appli- cation an the X-Server requests the repaint by the mentioned events. Regards, Stephan
Re: Profiling LyX-140 on Mac
Martin Vermeer wrote: On Wed, 2005-05-11 at 17:41, Asger Alstrup wrote: Martin Vermeer wrote: On Wed, 2005-05-11 at 17:02, Lars Gullik Bjønnes wrote: How can events be reordered? Precisely my question. Did you check that your keyboard queue is really a queue, and not a stack? There is no keyboard (or other) queue in the patch that I committed. Just an idea... maybe a bad one. I think, there is an implicit stacking everytime event driven reentrance happens. I suspect you will use the call stack as event stack too, when you call processevents() inside an action to handle a keypress. Scenario: Fast typing The last time I tested lyx produces The last tim I tested lyxe When handling the keypress e of time the processevents entered a new level on top of the call stack and the rest of the sentence is handled by that. After returning from that level the pending e is processed and appended at the end of the text. Regards, Stephan
Re: Indentation (was: [PATCH] Fix memory leaks)
Henner Zeller wrote: Hi, two short remarks; I usually put these lines in every file I write /* Emacs: * Local variables: * c-basic-offset: 8 * End: * vi:set tabstop=8 shiftwidth=8 nowrap: */ which is understood by emacs and vim so these editors are switched to the 'correct' indentation style automatically (without 20 Mails/Thread necessary :-) Another: use 'diff -uw' to see see changes which are not due to whitespaces. One short remark. The line with * vi:... doesn't work with all vi-clones, I'm using the nvi and read in the documentation: modelines, modeline [off] If the modelines option is set, ex/vi has histori- cally scanned the first and last five lines of each file as it is read for editing, looking for any ex commands that have been placed in those lines. After the startup information has been processed, and before the user starts editing the file, any commands embedded in the file are exe- cuted. Commands were recognized by the letters "e" or "v" followed by "x" or "i", at the beginning of a line or following a tab or space character, and fol- lowed by a ":", an ex command, and another ":". This option is a security problem of immense pro- portions, and should not be used under any circum- stances. This option will never be implemented. Greetings from the security paranoid Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: lyx-devel: Footnote bug
Jean-Marc Lasgouttes wrote:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Dekel == Dekel Tsur [EMAIL PROTECTED] writes: | |
Lars Dekel No the problem is footnote specific. If I have
Lars a\footnote{foo} | Dekel b, then the generated LaTeX code is:
Lars | | a\footnote{% | foo}% | b
Lars will
a\footnote{%
foo}
b
Lars work correctly?
Probably. Do you really need those carriage return?
What about a\footnote{ foo} b?
It would be then:
a\footnote{%
foo}
b
Are you loosing a space again?
Stephan
[EMAIL PROTECTED] | beusen Solutions GmbH
fon: +49 30 549932-62| Landsberger Allee 366
fax: +49 30 549932-21| 12681 Berlin, Germany
Re: Crash on second screen
Lars Gullik Bjønnes wrote: Bradford Castalia [EMAIL PROTECTED] writes: | LyX version 1.1.6fix1 crashes on the second screen (localhost:0.1) | with the error message BadMatch (invalid parameter attributes). | Startup, with no command line arguments, completes with no apparent | problems. The Help menu is invoked and the Introduction document | selected. Status messages flash quickly in the bottom pane of the | LyX window; I think that an X Server action may happen just before | the crash. Ok... tell us (me) how to setup a second screen so that we can test this. % man xinit :) On a Linux system... * After starting the first X-Server (per run level 3 or so) * type Ctrl-Alt-F1 * login as normal user * xinit -- /usr/X11R6/bin/X :1 Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: Latest CVS breaks arabic support
Andre Poenitz wrote: I want to be able to run my English keyboard as is in most applications, and simultaneously be able to do Arabic/Farsi/etc in LyX. aol me too /aol But I also understand it is not The Right Thing and creates a lot of troubles for LyX... I think the situaton is even a bit more complicated. Sometimes I want to use a German and an English key mapping in different places in the same document. The current situation is pretty nice for this: Simply change keymaps within LyX. I don't know whether it is possible to change the keymap that X uses from within an application only for this application and mabe only for a limited time (shorter than the lifetime of the app). Anybody with more insight? No, as I know, it isn't possible. The keyboard mapping is X-Server global. Changes to it are possible with the xmodmap client and all X-clients get an UnmapNotify/MapNotify notify event if the keyboard is changed. Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: Compiling with Purify
Juergen Vigna wrote: On 23-Jul-2001 Jean-Marc Lasgouttes wrote: Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael Hi, when running Purify, it complains that it has to link a Michael directory. Could you please tell me what option Michael -Wl,/usr/openwin/lib means when linking binary file lyx. I think it means search libraries in /usr/openwin/lib (probably like -L). As much as I know of this stuff it means that at runtime it searches there for the dynamic libraries, while -L searches for the libraries at linktime there. So normally you need both, -L/usr/openwin/lib for linking stage and -Wl,/usr/openwin/lib so that the binary does find it when it runs. This is needed when you don't want to add certain lib directories to the configuration of you dynamic linker, on linux /etc/ld.so.conf) AFAIK: The switch -Wx,z is given to cc to hand the argument z to the compile stage x. That means for the example above: Hand /usr/openwin/lib to the stage l(linker) = a directory name as parameter (as reported by purify) = nonsense. The correct command line option is -Wl,-L/usr/openwin/lib or for runtime search -Wl,-R/usr/openwin/lib on solaris. The gnu linker maybe silently ignores the strange stuff or interprets the -Wl,/usr/openwin/lib in a non-standard manner. Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: configur latest cvs
Andre Poenitz wrote: On Thu, Oct 18, 2001 at 03:55:29PM +0200, Jean-Marc Lasgouttes wrote: Do you have a lyx binary in /usr/bin/X11 (and /usr/bin/X11 in your path?). If you do then blame your distributor (SuSE, if I am not mistaken) :) Where should the lyx bineary put by distributors in an ideal world? [And why?] Normally the binary is installed in /usr/X11R6/bin... The problem is not the real location. SuSE linux initializes the PATH environment variable with a clever mechanism: they look for the X11 directory to use the right one. But they're using a strange order for that: /usr/bin/X11,/usr/X11R6/bin,/usr/X11/bin. Unfortunately they added the symlink /usr/bin/X11 - ../X11R6/bin too... so X11 binaries now are found in /usr/bin/X11. I have changed the order of the lookup after installing my linux-laptop in /etc/csh.login. (I'm root there, I can do it :) Now the relevant part of /etc/csh.login reads as follows: if ( -d /usr/X11R6/bin ) then set _xpath=( /usr/X11R6/bin $_xpath ) else if ( -d /usr/X11/bin ) then set _xpath=( /usr/X11/bin $_xpath ) else if ( -d /usr/bin/X11 ) then set _xpath=( /usr/bin/X11 $_xpath ) endif I don't like the SuSE default too. Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: BUGREPORT: lyxpipe deletion
Juergen Vigna wrote: On 18-Oct-2001 Moritz Moeller-Herrmann wrote: On startup lyx could check if another lyx process of the same user was running and if not it could just delete the lypipe. This would be a good idea, the problem is how to detect in a portable way that the user is running another lyx process. Netscape creates a symlink in the directory $HOME/.netscape % ls -l .netscape/lock lrwxrwxrwx 1 witt 17 Oct 17 08:41 .netscape/lock - 172.22.1.250:2454 % The Unix platforms should support symlinks all... The logic is something like: 1. Create the symlink on startup, use IP-Addr:Processnumber 2a. If this succeeds = all ok. 2b. If it fails = read symlink and check for machine and presence of the process 3a. If it is the same machine and the process is not there (kill(pid,0)==-1) then remove the symlink, start over at 1. I cannot contribute any code, because I have no recent compiler... :( Hope this helps, Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: BUGREPORT: lyxpipe deletion
Andre Poenitz wrote:
On Fri, Oct 19, 2001 at 11:50:33AM +0200, Stephan Witt wrote:
1. Create the symlink on startup, use IP-Addr:Processnumber
How do you get The IP-address of some machine?
This logic is flawed.
You need the IP-address of your own machine to
compare with the IP-address used in constructed symlink.
Some code (error checking ommitted) to get the own IP address:
char * GetIpAddress (void)
{
struct utsname name ;
struct hostent *hp ;
struct in_addr in;
uname(name) ;
hp = gethostbyname(name.nodename);
(void) memcpy(in.s_addr,*hp-h_addr_list,sizeof (in.s_addr));
return inet_ntoa (in) ;
}
I know, this is not really robust. One have to use gethostbyname_r
to be reentrant, avoid inet_ntoa and so on. But the idea is like that.
Stephan
[EMAIL PROTECTED] | beusen Solutions GmbH
fon: +49 30 549932-62| Landsberger Allee 366
fax: +49 30 549932-21| 12681 Berlin, Germany
Re: BUGREPORT: lyxpipe deletion
Andre Poenitz wrote: On Fri, Oct 19, 2001 at 12:11:06PM +0200, Stephan Witt wrote: How do you get The IP-address of some machine? This logic is flawed. You need the IP-address of your own machine to My machine can have any number of IP adresses, including 0, 1, and 42. So which is the right one? The code gets the first one. Creates the symlink or compares with the content of the symlink created by the same code running by another instance of lyx (which is using the first one too). No problem. I cannot think of a machine which has no name and no interface these days. That means no IP at all. And there is an error then and you can fall back to 127.0.0.1. I know, this is not really robust. One have to use gethostbyname_r to be reentrant, avoid inet_ntoa and so on. But the idea is like that. Maybe it would even help in most cases, but so does some alias or wrapper script... I wanted to answer the question: How can I get my IP address? Nothing more. Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Re: CVS: Compile problem on Solaris
Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Tue, Dec 04, 2001 at 12:00:46AM +0100, Lars Gullik Bjønnes wrote: Ok, what is munmap's prototype on your box? | #ifdef __STDC__ | #if (_POSIX_C_SOURCE 2) | [...] | extern int munmap(void *, size_t); | [...] | #else | [...] | extern int munmap(caddr_t, size_t); and what is caddr_t? my guess is char* Yes, it is. /usr/include/sys/types.h:typedef char *caddr_t; /* ?core address type */ Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-62| Landsberger Allee 366 fax: +49 30 549932-21| 12681 Berlin, Germany
Sun CC 6.0 Update 2
Dear André, today I tried to compile lyx on Solaris with Sun's CC. I know that Lars doesn't like old and broken compilers, that's why I gave the newly installed version of Sun's CC a try. But I cannot decide if I got stuck because of a compiler (mis)feature or if it is another problem. Anyway, I'll give the details. 1. Download lyx-1.2.0pre4.tar.gz 2. Install bxform-089.tgz from ftp.lyx.org 3. Run configure with CC=cc CXX=CC LD_LIBRARY_PATH=/usr/local/lib:/usr/openwin/lib ./configure \ --x-includes=/usr/openwin/include --x-libraries=/usr/openwin/lib Configuration Host type: sparc-sun-solaris2.7 Special build flags:assertions included-libsigc forms-image-loader C Compiler: cc C Compiler flags: -g C++ Compiler: CC C++ Compiler flags: -g Linker flags: Frontend: xforms libXpm version: 4.10 libforms version: 0.89.6 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx 4. make Fails with: make[3]: Entering directory `/home/witt/netsrc/lyx-1.2.0pre4/src/mathed' source='math_arrayinset.C' object='math_arrayinset.lo' libtool=yes \ depfile='.deps/math_arrayinset.Plo' tmpdepfile='.deps/math_arrayinset.TPlo' \ depmode=none /bin/sh ../../config/depcomp \ /bin/sh ../../libtool --mode=compile CC -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../../boost -I/usr/openwin/include -g -c -o math_arrayinset.lo `test -f math_arrayinset.C || echo './'`math_arrayinset.C CC -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../../boost -I/usr/openwin/include -g -c math_arrayinset.C math_arrayinset.C, line 48: Error: Could not find a match for std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar::vector(std::istream_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, char, std::char_traitschar, int, std::istream_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, char, std::char_traitschar, int). 1 Error(s) detected. I'm unable to interpret this error. I'll attach the compressed config.log. Kind regards, Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-426 | Landsberger Allee 366 fax: +49 30 549932-921 | 12681 Berlin, Germany config.log.gz Description: Binary data
Re: [PATCH]: trivial fix for bug #415.
Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | On Wed, 22 May 2002, Lars Gullik Bjønnes wrote: Boost signals however delegates creation of functions objects and binding to two other libs, with sigc++ this is integrated in the signal/slot code. | Not quite as nice then. What is not quite as nice? I'd argue that SigC is not as nice, since it mixes idoms. boost::signals has them separated so that you can both change the bining lib without telling boost::signals, and the same with the boost::function lib (library for delayed calling of functions). Am I correct in beliving that gtkmm cannot exist without sigc++, and that if gtkmm is installed then a libsigc++ will also be installed? (so we won't have to provide sigc++ with lyx as we do now) | Now that libsigc++ is more wide spread (ie. when it was included few | major distros had a useful version of it) I want to remove it from the | dist -- whether we require it for all signals or just for the gtk | stuff. It seems to not be disted with RH. What about other platforms? DEC, Sun, ... -- [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-426 | Landsberger Allee 366 fax: +49 30 549932-921 | 12681 Berlin, Germany
Re: portable shell scripts
Angus Leeming wrote:
I am trying to introduce some of the changes I've made in my wrappers tree
back into the cvs, but I have a problem.
In the xforms/forms directory is a shell script, fdfix.sh that is used to
manipulate the output from fdesign to a form suitable for LyX. I have added
this:
INTRO_MESSAGE=// File generated by fdesign from ${FDFILE} \n\
// and modified by fdfix.sh for use by LyX.\n\n\
// WARNING! All changes made to this file will be lost!\n\n\
// Copyright $DATE the LyX Team\n// Read the file COPYING
echo ${INTRO_MESSAGE} ${HOUT}
It works fine of the Tru64 machine, but on the Linux-alpha one results in
this:
aleem@thorax:forms$ more form_aboutlyx.C
// File generated by fdesign from form_aboutlyx.fd \n// and modified by
fdfix.sh for use by LyX.\n\n// WARNING! All changes made to this file will be
lost!\n\n// Copyright 2002 the LyX Team\n// Read the file COPYING
\n#include config.h
#include forms_gettext.h
#include gettext.h
Has anyone any ideas?
I propose this one:
#!/bin/sh
HOUT=file.out
FDFILE=file.fd
DATE=`date`
cat - ${HOUT} EOF
// File generated by fdesign from ${FDFILE}
// and modified by fdfix.sh for use by LyX.
// WARNING! All changes made to this file will be lost!
// Copyright $DATE the LyX Team
// Read the file COPYING
EOF
Greetings,
Stephan
[EMAIL PROTECTED] | beusen Solutions GmbH
fon: +49 30 549932-426 | Landsberger Allee 366
fax: +49 30 549932-921 | 12681 Berlin, Germany
Re: portable shell scripts
Jean-Marc Lasgouttes wrote:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Andre is not the whole world.
Lars I read a lot of shell scripts and this contruct is not often
Lars used. (it is often used, but almost never for plain variables)
Again:
${foo}
- it does not hurt
- it works always
Yes. I would add to this list:
- it is conform to makefile syntax
Because it is so easy to mix make and shell files
I'm using ${foo} because the context switch
between both worlds is easier.
And sometimes I'm using constructs like
${foo:=foo} or ${foo:-foo}.
Those constructs match better if I'm using ${foo} too.
$foo
- less typing. Better if you are lazy
It is like adding const everywhere in C++: you rarely _need_ it, but
somehow it is better and helps in the long run.
Greetings,
Stephan
[EMAIL PROTECTED] | beusen Solutions GmbH
fon: +49 30 549932-426 | Landsberger Allee 366
fax: +49 30 549932-921 | 12681 Berlin, Germany
Re: po/POTFILES.in
Andre Poenitz wrote: On Mon, Jul 01, 2002 at 12:22:36PM +0200, Jean-Marc Lasgouttes wrote: Andre Then perhaps Andre tr [A-Z._] [a-zzz] POTFILES.in | paste - POTFILES.in | sort | Andre cut -f 2 Isn't this completely unportable? What an ugly solution... What's unportable there? I always thought that the text utils were available in every *nix? I had to admit, that I'm surprised of the existance of paste. I've learned a new unix command today! But I don't understand the problem of portability of sort. Maybe, it's a environment thing? What about % LC_COLLATE=C sort POTFILES.in Possibly an additional parameter -f for sort is also usable. This should be portable. Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-426 | Landsberger Allee 366 fax: +49 30 549932-921 | 12681 Berlin, Germany
Re: [ANNOUNCE] LyX 1.2.1 is released
Jean-Marc Lasgouttes wrote: We are glad to announce the release of LyX 1.2.1. First of all, thanks for the good job... Recently I managed to install the new LyX on the Sun-Server of our site. There was one complaint now: The dvi-preview (View-DVI) doesn't respect the current settings of Paper orientation at least (Size?). The cause of this is the check for the presence of the parameter \view_dvi_paper_option -paper for the viewer. Maybe, there is an issue here with install? I think, if the previewer is xdvi, then this entry should be made automagically or it should be assumed by LyX itself. Greets, Stephan [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-426 | Landsberger Allee 366 fax: +49 30 549932-921 | 12681 Berlin, Germany
Re: xforms 1.0 final released
Jean-Marc Lasgouttes wrote: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Angus Leeming [EMAIL PROTECTED] writes: | Ok, it's out. Lars | Lars | Are we going to keep support for xforms 0.88 and 0.89 in LyX Lars 1.3? Lars _I_ would like us to ditch support for 0.88 and 0.89 at once, Lars especially 0.88. So what was the final decision on this? I think we should get rid of 0.88 now, since it is the most problematic. Note however that this will cause problems for people who use solaris and for cjk-lyx, because of shortcomings ion xforms support for input methods. But this problems have to be faced and solved anyway. JMarc Yesterday I tried to compile 1.0-release on my solaris machine. I can't say it compiles out of the box, but the problems where solveable. But I didn't try to install the shared libs, because of the suspected trouble with older lyx binaries. Later I'll give it a try, when lyx-1.2.2 or lyx 1.3 is out. Stephan
Re: xforms 1.0 final released
Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan Yesterday I tried to compile 1.0-release on my solaris Stephan machine. I can't say it compiles out of the box, but the Stephan problems where solveable. But I didn't try to install the Stephan shared libs, because of the suspected trouble with older lyx Stephan binaries. Stephan Later I'll give it a try, when lyx-1.2.2 or lyx 1.3 is out. I'd be interested to know whether you can get the compose key to work correctly. I guess it isn't work. My keyboard has an american PC mapping. The xev output contains KeyPress event, serial 20, synthetic NO, window 0x481, root 0x36, subw 0x0, time 142271521, (79,62), root:(166,107), state 0x0, keycode 117 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 characters: KeyRelease event, serial 21, synthetic NO, window 0x481, root 0x36, subw 0x0, time 142271574, (79,62), root:(166,107), state 0x0, keycode 117 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 characters: when I press the W95-Menu key. The /usr/X11R6/bin/xterm on solaris (built from source) gives an a-umlaut, when I press the following keys in sequence: Multi_key, quotedbl, a. Sun's /usr/openwin/bin/xterm on one host did the same, on another host it is broken. The key sequence mentioned above gives a. Don't know how to interpret this. The new built fdesign (1.0-release) binary doesn't produce an a-umlaut either. Stephan
Re: [WARNING] Bad bug in lyx 1.2.2 configure script
Jean-Marc Lasgouttes wrote: Michael == Michael Abshoff [EMAIL PROTECTED] writes: Michael This bug bit me couple of times when I set up my new Laptop. Michael I never suspected the configure-script and chased the bug for Michael a week. Yes, it is ugly. Note that kudos for spotting this should go to Dominik Vogt. JMarc Ofcourse this isn't an excuse for this bug, but... Once upon a time there was a rule: Never configure and compile software as root! After a succesful build you should become root with su (without hyphen!) and do a make install, if you tested this piece of software and trust it. I'm working without the magic power of root as much as possible. And on my laptop and my home box there it is the same. Stephan
Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Martin Vermeer wrote: On Fri, 2006-03-17 at 10:27 +, Angus Leeming wrote: Martin Vermeer [EMAIL PROTECTED] writes: you should not be able to accidentally change that file's date stamp (yes, that's the most hateful thing about re-saving unchanged documents -- and no way within the known laws of physics to revert it!) touch -t 200602291200 myfile.lyx ? Or is that a perpetual motion machine? Angus It might as well be if you don't remember what the time stamp was. Better solution would be to have your LyX docs in a version control system. I wonder how many people have. We have it on our site. We are using networking CVS and readonly checkouts. I have distributed locally a patched LyX with two changes: 1. checkOut (cvs edit) has a real implementation 2. checkIn (cvs commit) displays error messages in case of occurance With these modifications we're nearly pleased with LyX+Version Control. One issue is left open: you have to add a file to the repository manually (via cmdline) because of LyX using RCS as default for registrer. Regards, Stephan --
Re: Please add short bug description to subject
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Hi, Paraphrasing what Stefan said in another post, I'd be grateful if people posting about bugs could: When you post something about a bug, please add the bug's short description to the subject of the post. This plus a link to the bug entry (so that I can click on it): http://bugzilla.lyx.org/show_bug.cgi?id= Abdel. But I guess the mails would be classified as SPAM more often then... Stephan
[patch for [Bug 1656] command gnome-session-save kills lyx!]
Hi Richard,
you moved the target milestone of bug 1656 to 1.5.x. Now I had the time
and energy to check my proposal to fix the bug again. I modified the
code to fit the new 1.5.x code base. My tests with OpenSuSE 10.2 and Qt
4.1.2 went well. The program isn't exiting prematurely anymore and in
case of unsaved changes the user is asked for proper action just like on
quit of LyX.
The idea was: the default session save action of Qt is to send an close
event to all windows (in method commitData()). I replaced it by an call
to theBufferList().quitWriteAll(). This didn't work with older Qt
versions apparently. Now I have no problem with my current Qt 4.1.2 anymore.
The resulting patch is attached and in bugzilla too.
Regards,
Stephan
Original-Nachricht
Betreff: [Bug 1656] command gnome-session-save kills lyx!
Datum: Mon, 20 Aug 2007 13:38:44 +0200
Von: [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
http://bugzilla.lyx.org/show_bug.cgi?id=1656
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #728 is|0 |1
obsolete||
--- Additional Comments From [EMAIL PROTECTED] 2007-08-20
13:38 ---
Created an attachment (id=2110)
-- (http://bugzilla.lyx.org/attachment.cgi?id=2110action=view)
Updated patch for bad exit on gnome-session-save
I've updated my patch for 1.5.X and tested it with activated (comments
removed)
code.
The patch works with OpenSuSE 10.2 and Qt 4.1.2. Cannot test others
environments.
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp (Revision 19655)
+++ src/frontends/qt4/GuiApplication.cpp (Arbeitskopie)
@@ -28,6 +28,7 @@
#include support/Package.h
#include BufferView.h
+#include BufferList.h
#include Color.h
#include debug.h
#include FuncRequest.h
@@ -316,6 +317,22 @@
// X11 specific stuff goes here...
#ifdef Q_WS_X11
+
+void GuiApplication::commitData(QSessionManager sm)
+{
+ /// The implementation is required to avoid an application exit
+ /// when session state save is triggered by session manager.
+ /// The default implementation sends a close event to all
+ /// visible top level widgets when session managment allows
+ /// interaction.
+ /// We are changeing that to write all unsaved buffers...
+ if ( sm.allowsInteraction() ) {
+ if ( !theBufferList().quitWriteAll() ) {
+ sm.cancel();
+ }
+ }
+}
+
bool GuiApplication::x11EventFilter(XEvent * xev)
{
if (!currentView())
Index: src/frontends/qt4/GuiApplication.h
===
--- src/frontends/qt4/GuiApplication.h (Revision 19655)
+++ src/frontends/qt4/GuiApplication.h (Arbeitskopie)
@@ -25,6 +25,7 @@
#include QApplication
#include QTranslator
+#include QSessionManager
namespace lyx {
@@ -106,6 +107,7 @@
std::mapint, boost::shared_ptrsocket_callback socket_callbacks_;
#ifdef Q_WS_X11
+ void commitData(QSessionManager sm);
public:
bool x11EventFilter (XEvent * ev);
#endif
Re: [patch for [Bug 1656] command gnome-session-save kills lyx!]
Andre Poenitz schrieb:
On Tue, Aug 21, 2007 at 10:31:57AM +0200, Stephan Witt wrote:
// X11 specific stuff goes here...
#ifdef Q_WS_X11
+
+void GuiApplication::commitData(QSessionManager sm)
+{
+ /// The implementation is required to avoid an application exit
+ /// when session state save is triggered by session manager.
+ /// The default implementation sends a close event to all
+ /// visible top level widgets when session managment allows
+ /// interaction.
+ /// We are changeing that to write all unsaved buffers...
+ if ( sm.allowsInteraction() ) {
+ if ( !theBufferList().quitWriteAll() ) {
Spacing.
Thanks. Very clear. Did you try it?
I'll provide a modified patch when there is a need for.
Do you want the if (sm.allowsInteraction()) { style?
Stephan
Re: [patch for [Bug 1656] command gnome-session-save kills lyx!]
Abdelrazak Younes schrieb:
Stephan Witt wrote:
Andre Poenitz schrieb:
On Tue, Aug 21, 2007 at 10:31:57AM +0200, Stephan Witt wrote:
// X11 specific stuff goes here...
#ifdef Q_WS_X11
+
+void GuiApplication::commitData(QSessionManager sm)
+{
+/// The implementation is required to avoid an application exit
+/// when session state save is triggered by session manager.
+/// The default implementation sends a close event to all
+/// visible top level widgets when session managment allows
+/// interaction.
+/// We are changeing that to write all unsaved buffers...
+if ( sm.allowsInteraction() ) {
+ if ( !theBufferList().quitWriteAll() ) {
Spacing.
Thanks. Very clear. Did you try it?
I'll provide a modified patch when there is a need for.
Do you want the if (sm.allowsInteraction()) { style?
Yes, that's what he meant. I'll go even further ;-)
if (sm.allowsInteraction() !theBufferList().quitWriteAll())
sm.cancel();
I am OK with the patch but I would like to know first if there are any
drawbacks, I am not on X11.
I tested this patch with Qt 4.1.2 and it is working without drawbacks.
AFAIK older Qt versions are not supported anymore were I had problems
with the popping up of the dialog asking the user to confirm the file
save operation. So two years ago the patch did not work (with Qt 3.x).
I cannot tell anything about the behaviour on Windows.
Do you need a new patch from me or will you change it yourself?
I'm online next week again.
Thanks,
Stephan
Re: [patch for [Bug 1656] command gnome-session-save kills lyx!]
Abdelrazak Younes schrieb: Stephan Witt wrote: Abdelrazak Younes schrieb: I am OK with the patch but I would like to know first if there are any drawbacks, I am not on X11. I tested this patch with Qt 4.1.2 and it is working without drawbacks. AFAIK older Qt versions are not supported anymore were I had problems with the popping up of the dialog asking the user to confirm the file save operation. So two years ago the patch did not work (with Qt 3.x). OK, thanks for the clarification. I cannot tell anything about the behaviour on Windows. I'll try without the #ifdef to test it out. Do you need a new patch from me or will you change it yourself? No, that's fine, I'll do it. Thank you! Stephan
Re: [patch for [Bug 1656] command gnome-session-save kills lyx!]
Abdelrazak Younes schrieb: Stephan Witt wrote: Abdelrazak Younes schrieb: Do you need a new patch from me or will you change it yourself? No, that's fine, I'll do it. Thank you! You are welcome. Please send a message to this list stating the following: I granted permission already in 2005. :) It was the 22nd of February 2005. Could one of the usual suspects add Stephan to the Contrib list please? IMHO I'm on the the list already. Thanks again. Stephan
Re: [patch for [Bug 1656] command gnome-session-save kills lyx!]
Abdelrazak Younes schrieb: Stephan Witt wrote: Abdelrazak Younes schrieb: Stephan Witt wrote: Abdelrazak Younes schrieb: Do you need a new patch from me or will you change it yourself? No, that's fine, I'll do it. Thank you! You are welcome. Please send a message to this list stating the following: I granted permission already in 2005. :) It was the 22nd of February 2005. Good, so why do I have to commit this for you? ;-) You know, it's not so easy to gain commit privileges ;) But I have not so many things to contribute anyway. Stephan
Re: Toolbars colors makes them unusable
Rainer Dorsch schrieb: Am Freitag, 31. August 2007 19:50 schrieb Pavel Sanda: I run lyx remove on the SLES9 machine and connect from a Debian etch machine with SSH. ssh -X or ssh -Y ? I have also lyx 1.4.3 on the SLES9 machine, this one runs in the same session flawless. lyx 1.4.3 is linked against QT3. Do you know which X setting is affected and how I could check that (or a term to google for)? i would search for Depth in your xorg.conf. Hmmm...I do not yet understand the concept. On the SLES which runs LyX, there is no XServer. Thus there is no color depth on the machine which runs LyX. On the client, which is a Debian etch machine and which runs the XServer, I get Section Screen Identifier Screen0 Device Card0 # Device radeon driver MonitorMonitor0 DefaultDepth24 i.e. a color depth of 24. That seems to be reasonable, any locally compiled version of LyX does not show and bad colors. Do I have to tell LyX on the SLES machine that the XServer it is displayed on the etch machine supports 24 bits color depth? How would I do that? No, you don't have to tell LyX about that. The Xlib code is aware of the properties of the Xservers (Screen) it is connected to. You may check that with the following command: % ssh -XC [EMAIL PROTECTED] xdpyinfo or % ssh -XC [EMAIL PROTECTED] /usr/X11/bin/xdpyinfo The output tells you about the default visual and it's depth. But I would guess that's not the problem. Stephan
Re: Toolbars colors makes them unusable
Rainer Dorsch schrieb: Am Montag, 3. September 2007 12:19 schrieb Stephan Witt: Rainer Dorsch schrieb: Am Freitag, 31. August 2007 19:50 schrieb Pavel Sanda: I run lyx remove on the SLES9 machine and connect from a Debian etch machine with SSH. ssh -X or ssh -Y ? I have also lyx 1.4.3 on the SLES9 machine, this one runs in the same session flawless. lyx 1.4.3 is linked against QT3. Do you know which X setting is affected and how I could check that (or a term to google for)? i would search for Depth in your xorg.conf. Hmmm...I do not yet understand the concept. On the SLES which runs LyX, there is no XServer. Thus there is no color depth on the machine which runs LyX. On the client, which is a Debian etch machine and which runs the XServer, I get Section Screen Identifier Screen0 Device Card0 # Device radeon driver MonitorMonitor0 DefaultDepth24 i.e. a color depth of 24. That seems to be reasonable, any locally compiled version of LyX does not show and bad colors. Do I have to tell LyX on the SLES machine that the XServer it is displayed on the etch machine supports 24 bits color depth? How would I do that? No, you don't have to tell LyX about that. The Xlib code is aware of the properties of the Xservers (Screen) it is connected to. You may check that with the following command: % ssh -XC [EMAIL PROTECTED] xdpyinfo or % ssh -XC [EMAIL PROTECTED] /usr/X11/bin/xdpyinfo The output tells you about the default visual and it's depth. But I would guess that's not the problem. I am not an expert reading these data, I did not see something suspicious, do you? No, it's all well, the X-server (your client machine) and the Xconnection is able to display true color (24 bit depth). Your problem is not the X-server. See the comments in your output below. It is IMHO a Qt-ABI-incompatibility. Maybe, you can force your lyx binary which is compiled and linked against Qt 4.2.1 to use the correct (?) shared library at runtime? I suspect something is fishy with your libQtCore.so.4 = /afs/bb/data/d3197/galaxy2/zLinux/qt-4.2.1//lib/libQtCore.so.4 line in ldd output... Are you sure it is compatible with libQtGui.so.4 = /afs/qt-4.2.1/lib/libQtGui.so.4 ? Stephan $ ssh -XC [EMAIL PROTECTED] xdpyinfo #user and sles-machine replaced name of display:localhost:43.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:70101000 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x305, revert to PointerRoot number of extensions:32 ATIFGLEXTENSION ATIFGLRXDRI ATITVOUT BIG-REQUESTS DAMAGE DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DRI XFree86-Misc XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number:0 That's the screen LyX should use: screen #0 number of screens:1 screen #0: dimensions:1600x1200 pixels (410x310 millimeters) resolution:99x98 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x3d depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa4031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:8 default visual id: 0x23 That's the visual LyX is using: 0x23 And this visual has true color capabilities. The LyX application may request the display of every pixmap up to 2^24 different colors. visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x24 class:TrueColor
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda schrieb: It does, I put it in. thanks (I don't understand what the x does.) it represents default hyperref settings. good night :) I like your affort to make a GUI for hyperref with pdf-support. I have one question: Many of my documents are using ERT to add hyperref and configure pdf-options. Are these already detected and converted? Stephan
Re: Compile issue of 1.4.2 with QT 3.0.5
Jean-Marc Lasgouttes wrote: José == José Matos [EMAIL PROTECTED] writes: José The patch I sent has this issue fixed. I send the patch again José attached. The patch is against the latest svn version. José Could you try and see if the attached patch works. It is the José only way to ask Jean-Marc to included it in the stable series. I'd like this patch to go in 1.4.3. Jose', if you feel confident that it improves the situation, please apply. We'll apply another one if problems remain. I've successfully tested the patch on my good old SuSE 8.1. Without the patch I failed to configure.py my user directory with the exception in checkTeXAllowSpaces(). After applying the patch it is fine. Regards, Stephan % ../lyx-1.4.x/configure --with-frontend=qt ... checking for python... /usr/bin/python checking for python version... 2.2 checking for python platform... linux2 ... Configuration Host type: i686-pc-linux-gnu Special build flags:assertions warnings use-ispell C Compiler: gcc C Compiler LyX flags: C Compiler flags: -W -Wall -I/usr/X11R6/include -g -O C++ Compiler: g++ (3.2.3) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -W -Wall -I/usr/X11R6/include -g -O Linker flags: Linker user flags: Qt Frontend: Qt version: 3.0.5 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx --
Re: Compile issue of 1.4.2 with QT 3.0.5
Jean-Marc Lasgouttes wrote: José == José Matos [EMAIL PROTECTED] writes: José The patch I sent has this issue fixed. I send the patch again José attached. The patch is against the latest svn version. José Could you try and see if the attached patch works. It is the José only way to ask Jean-Marc to included it in the stable series. I'd like this patch to go in 1.4.3. Jose', if you feel confident that it improves the situation, please apply. We'll apply another one if problems remain. I've just detected another phyton problem. The script lib/scripts/TeXFiles.py failed with Indexing files of type cls Traceback (most recent call last): File /home/witt/src/lyx/lyx-1.4.x/lib/scripts/TeXFiles.py, line 110, in ? for root,path,files in os.walk(dir): AttributeError: 'module' object has no attribute 'walk' Menu warning: menu entries Einstellungen...|i and TeX Information|I share the same shortcut. Indexing files of type cls Traceback (most recent call last): File /home/witt/src/lyx/lyx-1.4.x/lib/scripts/TeXFiles.py, line 110, in ? for root,path,files in os.walk(dir): AttributeError: 'module' object has no attribute 'walk' Indexing files of type cls Traceback (most recent call last): File /home/witt/src/lyx/lyx-1.4.x/lib/scripts/TeXFiles.py, line 110, in ? for root,path,files in os.walk(dir): AttributeError: 'module' object has no attribute 'walk' Regards, Stephan --
Re: Patches to support python 2.2 in lyx 1.4.4
José Matos wrote: On Thursday 21 September 2006 23:26, José Matos wrote: The second patch fixes the issues I have found in scripts. It should work now. OK, that should not work. I send another patch... FWIW the only difference is the addition of one line from __future__ import generators Hi José, I've tested the patched version of TeXFiles.py and python tells me that from __future__ import generators must be placed at the beginning of the file. So I send you the version which is working for me... Thank you, Stephan -- Index: TeXFiles.py === --- TeXFiles.py (Revision 15093) +++ TeXFiles.py (Arbeitskopie) @@ -33,6 +33,8 @@ # relies on python and kpsewhich (no shell command is used). # +from __future__ import generators + import os, sys, re cls_stylefile = 'clsFiles.lst' @@ -40,6 +42,54 @@ bst_stylefile = 'bstFiles.lst' bib_files = 'bibFiles.lst' +# this code was taken from twisted +# http://twistedmatrix.com/trac/browser/trunk/twisted/python/compat.py?rev=14178format=txt +# and allow us to use os.walk with python 2.2 +try: +os.walk +except AttributeError: +if sys.version_info[:3] == (2, 2, 0): +__builtin__.True = (1 == 1) +__builtin__.False = (1 == 0) +def bool(value): +Demote a value to 0 or 1, depending on its truth value + +This is not to be confused with types.BooleanType, which is +way too hard to duplicate in 2.1 to be worth the trouble. + +return not not value +__builtin__.bool = bool +del bool + +def walk(top, topdown=True, onerror=None): +from os.path import join, isdir, islink + +try: +names = os.listdir(top) +except OSError, e: +if onerror is not None: +onerror(err) +return + +nondir, dir = [], [] +nameLists = [nondir, dir] +for name in names: +nameLists[isdir(join(top, name))].append(name) + +if topdown: +yield top, dir, nondir + +for name in dir: +path = join(top, name) +if not islink(path): +for x in walk(path, topdown, onerror): +yield x + +if not topdown: +yield top, dir, nondir +os.walk = walk +# end compatibility chunk + def cmdOutput(cmd): '''utility function: run a command and get its output as a string cmd: command to run
Re: Preparing for alpha release
José Matos wrote: On Tuesday 14 November 2006 2:08 pm, Jean-Marc Lasgouttes wrote: Here is what I do these days for 1.4 releases. Thank you Jean-Marc, it helps a lot. :-) About version number: note that, with autoconf at least, if you name it anything else that 1.5.0svn or 1.5.0preN, the build system will default to configuring in stable mode (without debug and assertions). This may or may not be what you expect. It may be time to change that before release. Will something like this work? Index: config/lyxinclude.m4 === --- config/lyxinclude.m4(revision 15933) +++ config/lyxinclude.m4(working copy) @@ -16,7 +16,7 @@ else lyx_devel_version=no fi -if echo AC_PACKAGE_VERSION | grep 'pre' /dev/null ; then +if echo AC_PACKAGE_VERSION | grep -E 'pre|alpha' /dev/null ; then lyx_prerelease=yes JMarc grep -E is not supported when running on Solaris. Use egrep instead... Stephan
Re: Preparing for alpha release
José Matos wrote: On Wednesday 15 November 2006 3:19 pm, Stephan Witt wrote: grep -E is not supported when running on Solaris. Use egrep instead... I thought so, but I never remember which form is more universal. Does egrep has known problems? If not I will proceed with this change and do the release. AFAIK not. The (linux) man-page says that egrep is the same as grep -E. On Solaris grep -E works when using /usr/xpg4/bin/grep, BTW. But you cannot rely on having users /usr/xpg4/bin in front of /usr/bin in the PATH environment. Stephan --
Re: r16085, fix wrong toolbar icon size.
Andreas K. wrote: Peter Kümmel [EMAIL PROTECTED] writes: Bo Peng wrote: Hi, Peter, icons size is now stored in session, but is there a way to set icon size? Bo I wanna add it to the toolbar popup menu but JMarc and Georg don't like it. If an ordinary user's views is worth anything, I would say that I'd like to have access to icon size setting in the toolbar popup menu. Andreas If my view is worth anything, I would say that in case one can select theicon size they should look sensible after doing so. If that is possible with scaling it is ok. If it is not, then the only sensible option is to provide the hand crafted icon sets to chose from in parallel to the freedom of choice. Stephan --
Intermix fvwm and gnome [Was: Scons moves to its new home: development/scons]
Enrico Forestieri wrote: On Wed, May 17, 2006 at 08:36:15PM +0200, Andre Poenitz wrote: On Wed, May 17, 2006 at 12:34:43AM +0200, Enrico Forestieri wrote: and selecting your url and hitting Ctrl-Mouse should work. If only I could use fvwm with gnome! *shrug* I can use fvwm happily intermixed with native windows on my WinXP box at work so I would be surprised if the same could not be set up with a more X-ish environment like Gnome. I think that a window manager should be explicitely designed to work with gnome. I'm using Window Maker 0.80.1 at work for my desktop, a really old one. I have no problems to use the latest gnome applications from a remote server. The time for ssh -X -f server /opt/gnome/bin/gnome-terminal to open the terminal is below 2 seconds. But I think it's the performance of the system where gnome-terminal is running what matters. Stephan --
Re: long standing annoyance with tables
Juergen Spitzmueller wrote: Edwin Leuven wrote: Andre Poenitz wrote: Fine with me. I find i anooying myself. others? I'm also always deleting the lines, but only in order to get the booktabs ERT stuff in. My take on it is: add a border style combo to the tabular create dialog, which lets your chose: no borders, grid, booktabs (etc.). Shouldn't be too hard to implement (once the booktabs branch was merged). I second that. That's a very good idea. I always delete the lines when creating tables but I know my boss preferes the many lines style :) So a solution for both camps would be optimal. Regards, Stephan --
Re: I made an external inset for lilypond, but can't get the instant preview going
Helge Hafting wrote: Helge Hafting wrote: Georg Baum wrote: Helge Hafting wrote: Lyx discovered the existence of a converter, invoked lilypond which ran without error messages, but then lyx (using -dbg external,graphics) claimed that no file was produced. Very strange that. Note that I don't actually tell lilypond where to put the output file, but lilypond will then put it where it finds the input file. No, it will put it in the current directory (at least version 2.4.4) Urgh. Even 2.9.17 does this - I have now reported this bug to them. But view-pdf / view-dvi still works, I guess LyX is smart enough to run lilypond in the /tmp directory in these cases? Instantly viewing a .png in lyx certainly require a script though. I'll do that. Can you explain what the -b and -d arguments do? My version of lilypond does not have them. The stable lilypond releases 2.6 and 2.8 both have -b. Version 2.4 does not have it. Seems to me that trying to support lilypond 2.4 is a bad idea, as 2.4 don't export pdf like 2.6 and 2.8 do. Debian have lilypond 2.6, I don't know about other distributions, but there will be some time until lyx-1.5 anyway? I have two machines, one have lilypond 2.9 and the other will get 2.6 shortly. This way I'll get something that works for old lilypond as well as the development version. Hopefully this will also cover versions inbetween and the upcoming release as well. I hope supporting lilypond 2.4 isn't necessary, export/view-pdflatex really like to include a .pdf file, which lilypond 2.6 and up provides. I'm running SuSE9.3 Enterprise and they ship it with lilypond 2.4.4. I upgraded it to lilypond 2.8 already and it is easy to do for non-admin users too. So I would say support for 2.4 is not really needed. I'm very interested in seeing this feature usable. Thank you. Regards, Stephan --
Re: strace on lyx2lyx
Garst R. Reese wrote: 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. 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. Regards, Stephan
Re: support::regexMatch
Angus Leeming wrote:
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
[snip]
That being the case, this works, but isn't strict enough, allowing 'nested'
stuff like this hypothetical example:
$ x=M
$ echo ${HO${x}E}
/home/angus
The real shell won't allow this.
Just for curiosity: make will do it!
% cat Makefile
x=M
home=${HO${x}E}
all:
echo ${home}
% make
echo /home/witt
/home/witt
Regards,
Stephan
Re: Getting citep etc. to work for egs.cls
Andre Poenitz wrote:
On Wed, Feb 28, 2007 at 10:27:18PM +0100, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin The attached patches make both these mechanisms respond to the
Martin ProvidesNatbib textclass flag. I am not sure I did this right
Martin -- I am especially uncertain about the handling of the numeric
Martin vs. author-year thing. Shouldn't this also be in the .layout
Martin file if the class is loading natbib?
CiteEngine_enum getEngine(Buffer const buffer)
{
- return buffer.params().cite_engine;
+ BufferParams const p = buffer.params();
+ if (p.getLyXTextClass().provides(LyXTextClass::natbib)) {
+ if (p.cite_engine == biblio::ENGINE_NATBIB_NUMERICAL)
+ return ENGINE_NATBIB_NUMERICAL;
+ else
+ return ENGINE_NATBIB_AUTHORYEAR;
+ } else
+ return p.cite_engine;
}
What is the logic here?
Looks equivalent to
CiteEngine_enum getEngine(Buffer const buffer)
{
BufferParams const p = buffer.params();
if (p.getLyXTextClass().provides(LyXTextClass::natbib)
p.cite_engine != biblio::ENGINE_NATBIB_NUMERICAL)
return ENGINE_NATBIB_AUTHORYEAR;
return p.cite_engine;
}
Really? I think the aim was to override p.cite_engine for layouts providing
natbib...
Stephan
Re: Thought about the file format
John McCabe-Dansted wrote:
On 3/16/07, Andre Poenitz [EMAIL PROTECTED] wrote:
On Thu, Mar 15, 2007 at 10:51:24PM +0100, [EMAIL PROTECTED] wrote:
I have no problems with that as long as this is a concious decision of
the user. However, having things like my user name and
modification/access
date dumped silently into the file is no option.
An alternative would be to support an RCS format where everything is
explicitly saved forever, so e.g. you not only know when the document
was printed, but also can revert to the version for which pdflatex was
run successfully. This would have saved me many times from latex
producing some unintelligible error with no indication of how to fix
it or which change caused it.
This should allow you to not only tell if one document is newer than
another, but also if they are forked, and if they are forked how to
merge the changes.
I do this for most of my documents. The preamble needs one additional line:
\usepackage{rcs}
Then you start your document with something like the following:
ERT{
\RCS $Revision: 1.3 $
\RCS $Date: 2003/09/23 07:24:45 $
\RCS $RCSfile: MyFilename.lyx,v $
\RCS $State: Exp $}
Then you may add somewhere ERT{\RCSDate{}}, ERT{\RCSRCSfile{}} or
ERT{\RCSRevision{}} to get the values printed there.
Hope this helps,
Stephan
PS: Of course you have to install the package rcs.sty if not already
present on your system.
Re: Rename step one: insets/insetxxx == insets/InsetXxx.
Bo Peng wrote: As the C++ FAQ states, there is no reason to change extension when it already works. It is not a matter of life or death and all problems caused by the .C extension have been taken care of. HOWEVER, this file extension change has been discussed and agreed upon several times so let us just do it to avoid future discussions. Yesterday I got a trunk svn checkout up and running after modifying po/POTFILES.in (thanks for the hint Bo). Today I did a refresh and now I cannot compile lyx anymore (after running autogen.sh and configure): ... make[4]: Entering directory `/home/witt/Source/LyX/lyx-1.5.0/src/mathed' make[4]: *** Keine Regel vorhanden, um das Target »../../../trunk/src/mathed/InsetMathAMSArray.C«, benötigt von »InsetMathAMSArray.lo«, zu erstellen. Schluss. make[4]: Leaving directory `/home/witt/Source/LyX/lyx-1.5.0/src/mathed' ... Has anybody something forgotten or is it me who did something wrong? Stephan
Re: Rename step one: insets/insetxxx == insets/InsetXxx.
Stephan Witt wrote: Bo Peng wrote: As the C++ FAQ states, there is no reason to change extension when it already works. It is not a matter of life or death and all problems caused by the .C extension have been taken care of. HOWEVER, this file extension change has been discussed and agreed upon several times so let us just do it to avoid future discussions. Yesterday I got a trunk svn checkout up and running after modifying po/POTFILES.in (thanks for the hint Bo). Today I did a refresh and now I cannot compile lyx anymore (after running autogen.sh and configure): ... make[4]: Entering directory `/home/witt/Source/LyX/lyx-1.5.0/src/mathed' make[4]: *** Keine Regel vorhanden, um das Target »../../../trunk/src/mathed/InsetMathAMSArray.C«, benötigt von »InsetMathAMSArray.lo«, zu erstellen. Schluss. make[4]: Leaving directory `/home/witt/Source/LyX/lyx-1.5.0/src/mathed' ... Has anybody something forgotten or is it me who did something wrong? Ok, I got it. I did a make clean too, but it didn't help. After studying the Makefiles I figured out that one have to remove the *.Plo files manually. So I removed the .deps directories completely and repeated the configure step. Now the make is running fine. (Ofcourse the patch for po/POTFILES.in is required.) I don't know the correct fix for make clean and maybe it is as it should be... (I read the post of Andre' already, thanks for the hint. But I had to wait for the compiler before sending this mail. BTW, the linker took 412Mbytes memory for the final link stage.) Stephan
Re: remove decimal.lyx from the examples folder?
Uwe Stöhr wrote: Jean-Marc Lasgouttes schrieb: Uwe Can I remove the file decimal.lyx from /lib/examples? The content Uwe of this file is now covered by the EmbeddedObjects section Uwe 2.12.2. I guess you can. I did this. I'll leave the decimal files in /de and /fr until there is a translation of the EmbeddedObjects manual. regards Uwe Sorry, do you forgot to update lib/Makefile.am resp. lib/Makefile.in? make[2]: Entering directory `/home/witt/Source/LyX/lyx-1.5.0/lib' make[2]: *** Keine Regel vorhanden, um das Target »examples/decimal.lyx«, benötigt von »all-am«, zu erstellen. Schluss. make[2]: Leaving directory `/home/witt/Source/LyX/lyx-1.5.0/lib' Stephan
Re: Renamings
Andre Poenitz wrote:
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class RowPainter, which is used only
locally, so it does not show up in the .h. I'd prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
After moving and renaming LyxTabular the tree is broken...
Thank you.
Stephan
Re: Renamings
Andre Poenitz wrote:
On Thu, Apr 26, 2007 at 03:33:45PM +0200, Stephan Witt wrote:
Andre Poenitz wrote:
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class RowPainter, which is used only
locally, so it does not show up in the .h. I'd prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
After moving and renaming LyxTabular the tree is broken...
Thank you.
Done.
Thank you.
But I had to revert your LCursor = Cursor rename to make it compile.
I'll wait a little bit to check again later...
Stephan
Uninstalled LyX is not able to convert with between versions
If started from build-tree without install LyX cannot find the script lyx2lyx_version.py. It is looking into the source-tree but the generated script is in lib/lyx2lyx of the build-tree only. So it fails to open an older file... Stephan
Re: Uninstalled LyX is not able to convert with between versions
José Matos wrote: On Friday 27 April 2007 7:35:54 am Stephan Witt wrote: If started from build-tree without install LyX cannot find the script lyx2lyx_version.py. It is looking into the source-tree but the generated script is in lib/lyx2lyx of the build-tree only. So it fails to open an older file... The trick is to pass the environment variable PYTHONPATH= before lyx. It works this way. Indeed. Thank you. Stephan
Compiling LyX 1.4.x on opensuse 10.2
Dear JMarc, after succesfully building an 1.5.0svn checkout on the OpenSUSE 10.2 platform I tried to build the current 1.4.4 stable release because the distribution is shipped with 1.4.2. But I failed miserably and I didn't find any hint or cook-book like recipe what to do. Here's what I did: % svn checkout \ svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_4_X lyx-1.4.4 Then I did autogen.sh and created my build tree % (cd lyx-1.4.4 ; ./autogen.sh) % mkdir qt-1.4.4 % (cd qt-1.4.4 ; ../lyx-1.4.4/configure --with-frontend=qt) There was some output as usual but the end was not happy :( ... checking for IceConnectionNumber in -lICE... yes checking for moc2... not found checking for moc... /usr/bin/moc checking for uic... /usr/bin/uic checking whether uic supports -nounload... no checking for Qt library name... failed checking whether the Qt library is multi-threaded... no checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt ... Configuration Host type: i686-pc-linux-gnu Special build flags:assertions pch concept-checks stdlib-debug warnings use-ispell C Compiler: gcc C Compiler LyX flags: C Compiler flags: -Wextra -Wall-g -O C++ Compiler: g++ (4.1.2) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -Wextra -Wall-g -O Linker flags: Linker user flags: Qt Frontend: Qt version: Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx The following problems have been detected by configure. Please check the messages below before running 'make'. (see the section 'Problems' in the INSTALL file) % The config.log contains the following: Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable -languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-sys tem-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=- 4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) ... configure:26749: checking for Qt library name configure:26799: g++ -o conftest -g -O -Wextra -Wall conftest.cpp -lSM -lICE -lc -lm -lX1 1 -lqt-mt 5 conftest.cpp:40:22: error: qglobal.h: No such file or directory conftest.cpp:41:22: error: qstring.h: No such file or directory conftest.cpp:49: error: stray '\' in program conftest.cpp:49: error: stray '\' in program conftest.cpp: In function 'int main()': conftest.cpp:47: error: 'QString' was not declared in this scope conftest.cpp:47: error: expected `;' before 's' conftest.cpp:49: error: 'break_me_' was not declared in this scope configure:26805: $? = 1 configure: failed program was: So it doesn't find my Qt includes. When trying to pass some include directories it fails to detect the libraries. Where is the mistake? And why is it working with 1.5.0? How do you built your 1.4.4 binaries? Regards, Stephan ---
