Re: AlphaLinux problems

[Jean-Marc Lasgouttes]

 "Markku" == Markku Reunanen [EMAIL PROTECTED] writes:

Hello,

Markku On my Intel machines Lyx works fine, but when running it on my
Markku AlphaStation with RH6.0 I experience crashes. I compiled 1.0.4
Markku with egcs-2.91.66. The crashes occur whenever I try to undo a
Markku change or paste text. Cutting/copying the text works.

Could you provide us a backtrace of these problems? Which version of
xforms do you use?

JMarc

Re: AlphaLinux problems

[Markku Reunanen]

On 15 Oct 1999, Jean-Marc Lasgouttes wrote:

 Markku with egcs-2.91.66. The crashes occur whenever I try to undo a
 Markku change or paste text. Cutting/copying the text works.
 Could you provide us a backtrace of these problems? Which version of
 xforms do you use?

Xforms is 0.88-8, installed from RH Powertools 6.0 RPM. Lyx dies with
a message like this:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. If possible, please read 'Known bugs'
under the Help menu and then send us a full bug report. Thanks!
lyx: Attempting to save document /home/marq/text/tiheys.lyx as...
  1) /home/marq/text/tiheys.lyx.emergency
  Save seems successful. Phew.
Bye.
Aborted

I'm running Lyx 1.1.1pre2 now and it does exactly the same. Cutting and
pasting normal text seems to work ok, but undoing a paste crashes. Cutting
a formula or table works too, but pasting makes Lyx crash.

# Markku Reunanen # [EMAIL PROTECTED] # TTKK # Tampere, Hervanta # Marq/Fit^L!T #

Yet another cryptic error message

[Jean-Marc Lasgouttes]

Hi,

In my quest to compile lyx under dec cxx (mathed and insets do compile
now) I am faced with a new problem with DebugStrem. The error message
is:

cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 66: protected
  function "std::basic_streambufcharT, traits::sync [with
  charT=char, traits=std::char_traitschar]" is not accessible
  through a "std::basic_streambufchar, std::char_traitschar"
  pointer or object
sb2-sync();
-^

What does that mean? I am sure it used to work...

JMarc

Re: What is the convention for devel versions?

[Jean-Marc Lasgouttes]

 "Allan" == Allan Rae [EMAIL PROTECTED] writes:

Allan On 14 Oct 1999, Lars Gullik Bjønnes wrote:
 Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 
 | In configure, we have some code which checks the version numbers
 and | sets some things depending on whether we have a normal or
 debug | version. This obviously does not work anymore. To fix that,
 I have to | know what is the convention we take. So, is 'pre' in
 the version the | best way of denoting a devel version?
 
 _Or_ we could use the same arguments always?

Allan _Or_ we could say anything that doesn't fit x.x.0 is a devel
Allan version.

Note that currently the difference between devel/stable version is

- different compiler options: -O2 for stable (so that people do not
  ask again and again :), full warnings for gcc (-Wall -ansi).

- --with-warnings is enabled, meaning that the #warning directives are
enabled. This is the one I am worried about, even for x.x.non-zero
versions, which would be public in Allan's scheme (that I like
too).

So, we have to make-up our mind here.

JMarc

Re: lyx-1.1.1 locale problem fixed

[Jean-Marc Lasgouttes]

 "Kayvan" == Kayvan A Sylvan [EMAIL PROTECTED] writes:

Kayvan Hi all, I tracked down the locale problem to an unset
Kayvan definition in the newly revamped makefiles.

Well spotted. I applied the patch.

JMarc

Re: LyX 1.0.4.

[Stephan Witt]

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: Some compilation problems with latest cvs

[Andre' Poenitz]

 Lars And gcc 2.8.1 shows again that it is not suited for serious C++
 Lars development...
 
 Somehow I knew you would say that :)

aol on
Me too.
aol off

flame on
Using bleeding edge features is *not* "serious C++ development".
Serious C++ development is about modularization, lean interfaces, 
design of re-usable code and stuff like that. Hell, you can do 
"serious C++ development" in any programming language. But what is
currently done is far from that. My perception of the "development
process" is that five percent of the developers sprinkle bleeding edge
stuff all over the code, twenty percent try to work 
around them because they have to use non-conforming compilers and the
rest struggles to keep up. This is far, far from efficient.

There are quite a few thing I'd like to improve on lyx, I'd like to have
full xfig support, "native" inclusion of .gif and .tiff, a decent file
format and things like that. I have downloaded the latest CVS tree about
two dozen times now, even started a bit of coding now and then - of
course after a round of installing new stuff (be it a new autoconfig or
a new compiler) most of the time. But I usually get fed up after a
couple of hours since the sources are in a really pitiful state.
Implementation of a single function is usually spread over half a dozen
files, each written in a complete different coding style, internal interfaces
and the GUI is a mess,... (etc ad nauseam).

If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single
stable release and start over from scratch. The *last* step would be to
add compatibility to the existent LyX. I always thought that's what was
intented with the old 1.1 branch?
flame off

And no, I won't stop using LyX, because it does a pretty good job for
the things I need to do: write texts with math. But I won't stop
complaining either since I don't like to see valuable resources
(the developer's - i.e. YOUR! - work) wasted.

Andre'

PS: It's Friday, you know ;-)



--
Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik
[EMAIL PROTECTED] ... +49 3727 58 1381

More on compilers; Fwd:Compiling StarOffice and EGCS problems

[Arnd Hanses]

For the record (OS/2 compilers):

==BEGIN FORWARDED MESSAGE==
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Received: from trancentral ([212.74.44.49]) by mail.primeline.ch
  (Post.Office MTA v3.5.1 release 219 ID# 0-61525U1000L100S0V35)
  with SMTP id ch; Thu, 14 Oct 1999 20:37:07 +0200
From: "Adrian Gschwend" [EMAIL PROTECTED]
To: "XFree86 OS/2" [EMAIL PROTECTED],
"Buntspecht News" [EMAIL PROTECTED],
"Loren Bandiera" [EMAIL PROTECTED],
"Luc Van Bogaert" [EMAIL PROTECTED],
"Nick Marc" [EMAIL PROTECTED], "OS/2 News Service" [EMAIL PROTECTED],
"Roman Eglin" [EMAIL PROTECTED],
"Steve Wendt" [EMAIL PROTECTED],
"VOICE Newsletter" [EMAIL PROTECTED],
"Warpcast" [EMAIL PROTECTED]
Date: Thu, 14 Oct 1999 20:41:59 +0200 (CDT)
X-Mailer: PMMail 2.00.1500 for OS/2 Warp 4.05
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [XFreeOS2] Compiling StarOffice and EGCS problems
Sender: [EMAIL PROTECTED]
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
X-UIDL: 3be463aa0eeeff6daf34c66f47158dea


I talked to some people from StarOffice at Warpstock Europe and they
told me, that they have a serious problem with the OS/2 port of it.
Until now they used to compile the code with VAcpp 3.65 on OS/2 but now
they use "namespaces" in the code and because VAcpp 4.0 does not
support commandline compiling, they can't compile it on OS/2 anymore
(the project is simply too big for the VAcpp 4.0 workframe). On Linux
they use the Pentium optimized version of the GNU compiler and they
tried the same on OS/2. But unfortunately there is a problem in the
OS/2 port:

(Taken from http://www.goof.com/pcg/os2/#Bugs)

Known bugs:

emxomf now traps (sometimes?) when compiling with -g (debug) switch.
This is due to new format of debugging info (DWARF2). I do not know how
to fix this. Use A.OUT format (no -Zomf) for debugging and pmgdb. 

Solution: This happens because pgcc uses new stabs format (-gstabs+)
while emxomf understands only the standard stabs debugging info. I've
partialy fixed this by adding a tiny command-line preprocessor to gcc.
It scans argv[] and looks for both -Zomf and -g# where # is a number.
If it finds one, it replaces -g# by -gstabs#. This doesn't always help,
however. 
---

As you can see this is a limitation in EMX, we now have to find people
who are able to fix this (which will not be an easy task I think). We
are already in contact with Eberhard Mattes but we need more support.
If you think you are able to fix this, please get in contact with
Oliver Braun [EMAIL PROTECTED]. Please JUST reply if you really
think you can help StarDivision.

A StarOffice without debug informations can not be tested and if noone
can fix this limitation, Sun can not provide a new version for OS/2 !
So you see this is important for the future of StarOffice on OS/2.

Thanks for your support

Adrian Gschwend
@ OS/2 Netlabs
http://www.netlabs.org
===END FORWARDED MESSAGE===

We have released a.out (no -Zomf) till now, but for dll support (which
was rock solid with 1.04 in my tests) one should better move to -Zomf.
But then you can strip the binaries, so that no debugging code is left.
So the problem should be limited to the rare case that you must debug a
omf dll and depend on the stabs conversion to omf and dbg386. (Note you
can always try to build for debugging an a.out dll, but this is no
fun.)

Greets,

Arnd

More on compilers; Fwd:Compiling StarOffice and EGCS problems

[Arnd Hanses]

For the record (OS/2 compilers):

==BEGIN FORWARDED MESSAGE==
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Received: from trancentral ([212.74.44.49]) by mail.primeline.ch
  (Post.Office MTA v3.5.1 release 219 ID# 0-61525U1000L100S0V35)
  with SMTP id ch; Thu, 14 Oct 1999 20:37:07 +0200
From: "Adrian Gschwend" [EMAIL PROTECTED]
To: "XFree86 OS/2" [EMAIL PROTECTED],
"Buntspecht News" [EMAIL PROTECTED],
"Loren Bandiera" [EMAIL PROTECTED],
"Luc Van Bogaert" [EMAIL PROTECTED],
"Nick Marc" [EMAIL PROTECTED], "OS/2 News Service" [EMAIL PROTECTED],
"Roman Eglin" [EMAIL PROTECTED],
"Steve Wendt" [EMAIL PROTECTED],
"VOICE Newsletter" [EMAIL PROTECTED],
"Warpcast" [EMAIL PROTECTED]
Date: Thu, 14 Oct 1999 20:41:59 +0200 (CDT)
X-Mailer: PMMail 2.00.1500 for OS/2 Warp 4.05
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [XFreeOS2] Compiling StarOffice and EGCS problems
Sender: [EMAIL PROTECTED]
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
X-UIDL: 3be463aa0eeeff6daf34c66f47158dea


I talked to some people from StarOffice at Warpstock Europe and they
told me, that they have a serious problem with the OS/2 port of it.
Until now they used to compile the code with VAcpp 3.65 on OS/2 but now
they use "namespaces" in the code and because VAcpp 4.0 does not
support commandline compiling, they can't compile it on OS/2 anymore
(the project is simply too big for the VAcpp 4.0 workframe). On Linux
they use the Pentium optimized version of the GNU compiler and they
tried the same on OS/2. But unfortunately there is a problem in the
OS/2 port:

(Taken from http://www.goof.com/pcg/os2/#Bugs)

Known bugs:

emxomf now traps (sometimes?) when compiling with -g (debug) switch.
This is due to new format of debugging info (DWARF2). I do not know how
to fix this. Use A.OUT format (no -Zomf) for debugging and pmgdb. 

Solution: This happens because pgcc uses new stabs format (-gstabs+)
while emxomf understands only the standard stabs debugging info. I've
partialy fixed this by adding a tiny command-line preprocessor to gcc.
It scans argv[] and looks for both -Zomf and -g# where # is a number.
If it finds one, it replaces -g# by -gstabs#. This doesn't always help,
however. 
---

As you can see this is a limitation in EMX, we now have to find people
who are able to fix this (which will not be an easy task I think). We
are already in contact with Eberhard Mattes but we need more support.
If you think you are able to fix this, please get in contact with
Oliver Braun [EMAIL PROTECTED]. Please JUST reply if you really
think you can help StarDivision.

A StarOffice without debug informations can not be tested and if noone
can fix this limitation, Sun can not provide a new version for OS/2 !
So you see this is important for the future of StarOffice on OS/2.

Thanks for your support

Adrian Gschwend
@ OS/2 Netlabs
http://www.netlabs.org
===END FORWARDED MESSAGE===

We have released a.out (no -Zomf) till now, but for dll support (which
was rock solid with 1.04 in my tests) one should better move to -Zomf.
But then you can strip the binaries, so that no debugging code is left.
So the problem should be limited to the rare case that you must debug a
omf dll and depend on the stabs conversion to omf and dbg386. (Note you
can always try to build for debugging an a.out dll, but this is no
fun.)

Greets,

Arnd

Re: Overstrict ansi compliance?

[Lars Gullik Bjønnes]

"Arnd Hanses" [EMAIL PROTECTED] writes:

| On 14 Oct 1999 15:56:04 +0200, Jean-Marc Lasgouttes wrote:
| 
| If I don't mix C into too much, maybe this is a bit helpful:
| 
| - static functions: I cannot declare them extern "C" too. 
| 
| In the context of functions, 'extern' is the mutually exclusive
| opposite of 'static', when the fn is internal to the module.

Does this hold on linkage specifications?

| But I think you can/should/must always write and use a 'global' or
| 'static' or 'static inline' C++ wrapper fn (with better readable ADT
| declaration, if you want) for an 'extern "C" {int foo(int)}' fn:
| 
|   typedef ADTfoo int;
|   extern "C" { int foo(int x) }
| 
|   static inline ADTfoo
|   wrap_foo(ADTfoo x)
|   {
|   return ( foo(x) )
|   }

This example does not solve the problem, and this solution should
never be needed.

| But why not use a 'static inline' C++ wrapper fn which disappears after
| optimizing. But then the compiler uses only the wrapper.

It is often this wrapper that cannot have C++ linkage...the problem
arises when passing pointer to functioncs that have "C" linkage.

The problem is more like:

extern "C" {
int foo(int(*)(int));
}

int bar(int);

You are now not allowed to pass bar to foo because of different
linkage, so:

extern "C" {
int bar_wrapper(int i) {
return bar(i);
}
}

Would solve the problem (I hope)

Lgb

Math formula labels sometimes doesnot work

[Stephane LOUISE]

Hello everyone,

As you migth expect i have a little problem with lyx 1.0.4 :

With some formulas i didn't manage to add a label.
eg:
   . 
 d x   1 dn
  = -   
  dt   n^3   dt

I didnot see anything like that in "known bugs", that's
why i send this mail.
general information:
lyx 1.0.4
OS: solaris 2.5.1
WS: Sun Ultra 30
compiler: gcc 2.8.1

I was wondering if i am the only one with this problem and
if there exists some workaround.

mata ne
-- 
luigi
mailto:[EMAIL PROTECTED]

problem compiling lyx 1.0.4

[mossop]

I've had some problems compiling lyx 1.0.4, when I run the 'make all'
command I get the following error:-

..
make[1]: Leaving directory `/home/mossop/local/src/lyx-1.0.4/po'
make[1]: Entering directory `/home/mossop/local/src/lyx-1.0.4/src'
g++ -c -g -O2 -I. -I. -I../images  -I/home/mossop/local/lib   
-I/usr/openwin/include -DPACKAGE=\"lyx\"
-DLOCALEDIR=\"/home/mossop/local/share/locale\" ../src/main.C
In file included from ../src/main.C:13:
../src/lyx_main.h:69: field `act_' has incomplete type
../src/filetools.h: In method `void FilePtr::do_open(const class LString
, enum FilePtr::file_mode)':
In file included from ../src/main.C:16:
../src/filetools.h:97: warning: implicit declaration of function `int
fileno(...)'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/home/mossop/local/src/lyx-1.0.4/src'
make: *** [all] Error 1



This is on various sparcs/ultras running SunOS 5.5. I've tried fiddling
around a bit but to no avail. Any suggestions?

Re: Overstrict ansi compliance?

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars You are now not allowed to pass bar to foo because of different
Lars linkage, so:

Lars extern "C" { int bar_wrapper(int i) { return bar(i); } }

Lars Would solve the problem (I hope)

I can confirm that it does (at least to some extent, since I have not
been able to check that it links and runs yet...

JMarc

LyX screen font bug

[Jörg Ziefle]

Hi there,

I think I've discovered a bug in LyX concerning the selection of screen
fonts: If you want to use certain ttf fonts from windows ( yes, I know...
;-) ) in LyX, you can set them temporarily in the options-screen fonts
menu, but not in the lyxrc

reason: most fonts have whitespaces in their name

example:

-ttf-times new roman-medium-r-normal-regular-0-0-0-0-p-0-iso8859-1
 ---

LyX fails to parse this:

LyX: Unknown tag `new' [...]
LyX: Unknown tag `roman' [...]

I hope this could help.

Regards,

Joerg

-- 
Jörg Ziefle   e-mail: [EMAIL PROTECTED]
Allmandring 20 D 35   FAX:  +49 (0)441 2443 39433
70569 Vaihingen   Tel.:+49 (0)177 4389721
PGP Fingerprint: D9 13 E5 1F 10 3F 85 C7  A7 8A 4F 9A B5 6F 5B 80

Re: Yet another cryptic error message

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars You are now suddenly using a more modern standard library and
Lars there "sync" is a protected member, the right one to use is
Lars "pubsync", the function that will get into effect when
Lars MODERN_STL(?) is defined.

Is MODERN_STL defined for egcs? It is not with cxx, but I do not know
of a good test to define it.

However, I swear I got it to work earlier (before updating to your
path.h branch). Did you change something in configure?

JMarc

Re: Math formula labels sometimes doesnot work

[Jean-Marc Lasgouttes]

 "Stephane" == Stephane LOUISE [EMAIL PROTECTED] writes:

Stephane Hello everyone, As you migth expect i have a little problem
Stephane with lyx 1.0.4 :

Stephane With some formulas i didn't manage to add a label. eg: . d x
Stephane 1 dn  = -   dt n^3 dt

Stephane I didnot see anything like that in "known bugs", that's why
Stephane i send this mail. general information: lyx 1.0.4 OS: solaris
Stephane 2.5.1 WS: Sun Ultra 30 compiler: gcc 2.8.1

Hello,

Could you send a file showing this?

JMarc

Re: LyX screen font bug

[Jean-Marc Lasgouttes]

 "Jörg" == Jörg Ziefle [EMAIL PROTECTED] writes:

Jörg Hi there, I think I've discovered a bug in LyX concerning the
Jörg selection of screen fonts: If you want to use certain ttf fonts
Jörg from windows ( yes, I know... ;-) ) in LyX, you can set them
Jörg temporarily in the options-screen fonts menu, but not in the
Jörg lyxrc

Jörg reason: most fonts have whitespaces in their name

Jörg example:

Jörg   -ttf-times new
Jörg roman-medium-r-normal-regular-0-0-0-0-p-0-iso8859-1
Jörg ---

In this case, you have to enclose the font name in "quotes".

JMarc

Final Installation cleanup patch

[Kayvan A. Sylvan]

Hi folks,

Here's the last install problem from the lyx-1.0.4 to lyx-1.1.1 rollover.

Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.25
diff -u -u -r1.25 ChangeLog
--- ChangeLog   1999/10/15 10:33:31 1.25
+++ ChangeLog   1999/10/15 21:14:54
@@ -1,7 +1,10 @@
-1999-10-15  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+1999-10-15  Kayvan A. Sylvan  [EMAIL PROTECTED]
 
+   * lib/reLyX/Makefile.am: add missing Verbatim.pm and
+   RelyxFigure.pm to EXTRA_DIST so they will be included in tarball.
+
* src/Makefile.am: add a definition for localedir, so that locales
-   are found after installation (Kayvan)
+   are found after installation.
 
 1999-10-14  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
 
Index: lib/reLyX/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/reLyX/Makefile.am,v
retrieving revision 1.2
diff -u -u -r1.2 Makefile.am
--- lib/reLyX/Makefile.am   1999/10/12 14:08:52 1.2
+++ lib/reLyX/Makefile.am   1999/10/15 21:14:55
@@ -8,6 +8,7 @@
 EXTRA_DIST = BUGS BasicLyX.pm CHANGES CleanTeX.pm LastLyX.pm MANIFEST \
MakePreamble.pm ReadCommands.pm RelyxTable.pm reLyX.pod \
reLyXmain.pl syntax.default test.ltx test.lyx reLyX.man \
+   RelyxFigure.pm Verbatim.pm \
$(LYXDISTDIRS)
 
 LIBINSTFILES = *.pm *.pl README BUGS CHANGES reLyX.pod syntax.default Text/*.pm


-- 
Kayvan Aghaiepour Sylvan  | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan |   | Robin Gregory (2/28/92)

bug report: lyx-1.0.3/4 crashing when including .eps figures

[Russ Ross]

lyx-1.0.3 and 1.0.4 consistently crash when I include
a .eps figure (generated using xfig).  Lyx dies when I
include it, but when I restart lyx and load the
emergency backup file, the figure is included
successfully and I don't have any more problems. 
Including additional figures repeats the problem.

I've attached a simple (3k) figure that causes the
problem on my machine.

I compiled lyx with CXXFLAGS='-O2'. I'm running on a
Mandrake 6.0 Linux installation using pgcc (gcc
--version gives "pgcc-2.91.66").  I did the 1.0.4
build today to confirm that the bug happened in the
latest version. I have xforms V0.89.

- Russ
__
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
 test.eps

Re: Name of Extended Features manual

[Arnd Hanses]

On Thu, 14 Oct 1999 11:51:07 -0700 (PDT), [EMAIL PROTECTED]
wrote:

If you can come up with a better name, I think we'd all be happy to hear
it. "Extended" was just the best we could come up with at the time.

"Special F."

AH

Re: Possible bug with 1.0.4...

[Jean-Marc Lasgouttes]

 "Rod" == Rod Pinna [EMAIL PROTECTED] writes:

Rod   This message is in MIME format. The first part should be
Rod readable text, while the remaining parts are likely unreadable
Rod without MIME-aware tools. Send mail to
Rod [EMAIL PROTECTED] for more info.

Rod ---559023410-851401618-939949217=:8759 Content-Type: TEXT/PLAIN;
Rod charset=US-ASCII

Rod On 14 Oct 1999, Jean-Marc Lasgouttes wrote:

Rod Jean-Marc,

Rod Thanks for having a look at the problem. In the end, it turned
Rod out the it was a "stupid user" error. The problem was that the
Rod line:

Rod Also, I've got the following in the body of the text
Rod r_\textrm{wave}

Rod should have been r_\mathrm{wave}. It seems once LyX comes across
Rod the incorrect \textrm it gets a little confused. Anyway, I've
Rod attached an example file (gzipped) which displays the behaviour.
Rod If you load it, you should see the extra spaces between the
Rod normal and subscript characters.

How did you input the formula? Mathed gives errors when reading it:

Line ~76: Math parse error: Expected {. Maybe you forgot to enclose an argument in {}
Line ~76: Math parse error: Unmatching braces
 Math Panic, expect problems!

You can enter such text directly with math text mode (type M-m m while
already in math mode).

JMarc

Re: AlphaLinux problems

[Jean-Marc Lasgouttes]

> "Markku" == Markku Reunanen <[EMAIL PROTECTED]> writes:

Hello,

Markku> On my Intel machines Lyx works fine, but when running it on my
Markku> AlphaStation with RH6.0 I experience crashes. I compiled 1.0.4
Markku> with egcs-2.91.66. The crashes occur whenever I try to undo a
Markku> change or paste text. Cutting/copying the text works.

Could you provide us a backtrace of these problems? Which version of
xforms do you use?

JMarc

Re: AlphaLinux problems

[Markku Reunanen]

On 15 Oct 1999, Jean-Marc Lasgouttes wrote:

> Markku> with egcs-2.91.66. The crashes occur whenever I try to undo a
> Markku> change or paste text. Cutting/copying the text works.
> Could you provide us a backtrace of these problems? Which version of
> xforms do you use?

Xforms is 0.88-8, installed from RH Powertools 6.0 RPM. Lyx dies with
a message like this:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. If possible, please read 'Known bugs'
under the Help menu and then send us a full bug report. Thanks!
lyx: Attempting to save document /home/marq/text/tiheys.lyx as...
  1) /home/marq/text/tiheys.lyx.emergency
  Save seems successful. Phew.
Bye.
Aborted

I'm running Lyx 1.1.1pre2 now and it does exactly the same. Cutting and
pasting normal text seems to work ok, but undoing a paste crashes. Cutting
a formula or table works too, but pasting makes Lyx crash.

# Markku Reunanen # [EMAIL PROTECTED] # TTKK # Tampere, Hervanta # Marq/Fit^L!T #

Yet another cryptic error message

[Jean-Marc Lasgouttes]

Hi,

In my quest to compile lyx under dec cxx (mathed and insets do compile
now) I am faced with a new problem with DebugStrem. The error message
is:

cxx: Error: ../../../lyx-devel/src/support/DebugStream.C, line 66: protected
  function "std::basic_streambuf::sync [with
  charT=char, traits=std::char_traits]" is not accessible
  through a "std::basic_streambuf"
  pointer or object
sb2->sync();
-^

What does that mean? I am sure it used to work...

JMarc

Re: What is the convention for devel versions?

[Jean-Marc Lasgouttes]

> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:

Allan> On 14 Oct 1999, Lars Gullik Bjønnes wrote:
>> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> 
>> | In configure, we have some code which checks the version numbers
>> and | sets some things depending on whether we have a normal or
>> debug | version. This obviously does not work anymore. To fix that,
>> I have to | know what is the convention we take. So, is 'pre' in
>> the version the | best way of denoting a devel version?
>> 
>> _Or_ we could use the same arguments always?

Allan> _Or_ we could say anything that doesn't fit x.x.0 is a devel
Allan> version.

Note that currently the difference between devel/stable version is

- different compiler options: -O2 for stable (so that people do not
  ask again and again :), full warnings for gcc (-Wall -ansi).

- --with-warnings is enabled, meaning that the #warning directives are
enabled. This is the one I am worried about, even for x.x.non-zero
versions, which would be public in Allan's scheme (that I like
too).

So, we have to make-up our mind here.

JMarc

Re: lyx-1.1.1 locale problem fixed

[Jean-Marc Lasgouttes]

> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:

Kayvan> Hi all, I tracked down the locale problem to an unset
Kayvan> definition in the newly revamped makefiles.

Well spotted. I applied the patch.

JMarc

Re: LyX 1.0.4.

[Stephan Witt]

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: Some compilation problems with latest cvs

[Andre' Poenitz]

> Lars> And gcc 2.8.1 shows again that it is not suited for serious C++
> Lars> development...
> 
> Somehow I knew you would say that :)


Me too.



Using bleeding edge features is *not* "serious C++ development".
Serious C++ development is about modularization, lean interfaces, 
design of re-usable code and stuff like that. Hell, you can do 
"serious C++ development" in any programming language. But what is
currently done is far from that. My perception of the "development
process" is that five percent of the developers sprinkle bleeding edge
stuff all over the code, twenty percent try to work 
around them because they have to use non-conforming compilers and the
rest struggles to keep up. This is far, far from efficient.

There are quite a few thing I'd like to improve on lyx, I'd like to have
full xfig support, "native" inclusion of .gif and .tiff, a decent file
format and things like that. I have downloaded the latest CVS tree about
two dozen times now, even started a bit of coding now and then - of
course after a round of installing new stuff (be it a new autoconfig or
a new compiler) most of the time. But I usually get fed up after a
couple of hours since the sources are in a really pitiful state.
Implementation of a single function is usually spread over half a dozen
files, each written in a complete different coding style, internal interfaces
and the GUI is a mess,... (etc ad nauseam).

If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single
stable release and start over from scratch. The *last* step would be to
add compatibility to the existent LyX. I always thought that's what was
intented with the old 1.1 branch?


And no, I won't stop using LyX, because it does a pretty good job for
the things I need to do: write texts with math. But I won't stop
complaining either since I don't like to see valuable resources
(the developer's - i.e. YOUR! - work) wasted.

Andre'

PS: It's Friday, you know ;-)



--
Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik
[EMAIL PROTECTED] ... +49 3727 58 1381

More on compilers; Fwd:Compiling StarOffice and EGCS problems

[Arnd Hanses]

For the record (OS/2 compilers):

==BEGIN FORWARDED MESSAGE==
>Return-Path: <[EMAIL PROTECTED]>
>Delivered-To: [EMAIL PROTECTED]
>Message-Id: <[EMAIL PROTECTED]>
>Received: from trancentral ([212.74.44.49]) by mail.primeline.ch
>  (Post.Office MTA v3.5.1 release 219 ID# 0-61525U1000L100S0V35)
>  with SMTP id ch; Thu, 14 Oct 1999 20:37:07 +0200
>From: "Adrian Gschwend" <[EMAIL PROTECTED]>
>To: "XFree86 OS/2" <[EMAIL PROTECTED]>,
>"Buntspecht News" <[EMAIL PROTECTED]>,
>"Loren Bandiera" <[EMAIL PROTECTED]>,
>"Luc Van Bogaert" <[EMAIL PROTECTED]>,
>"Nick Marc" <[EMAIL PROTECTED]>, "OS/2 News Service" <[EMAIL PROTECTED]>,
>"Roman Eglin" <[EMAIL PROTECTED]>,
>"Steve Wendt" <[EMAIL PROTECTED]>,
>"VOICE Newsletter" <[EMAIL PROTECTED]>,
>"Warpcast" <[EMAIL PROTECTED]>
>Date: Thu, 14 Oct 1999 20:41:59 +0200 (CDT)
>X-Mailer: PMMail 2.00.1500 for OS/2 Warp 4.05
>MIME-Version: 1.0
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>Subject: [XFreeOS2] Compiling StarOffice and EGCS problems
>Sender: [EMAIL PROTECTED]
>Precedence: bulk
>Reply-To: [EMAIL PROTECTED]
>X-UIDL: 3be463aa0eeeff6daf34c66f47158dea
>

I talked to some people from StarOffice at Warpstock Europe and they
told me, that they have a serious problem with the OS/2 port of it.
Until now they used to compile the code with VAcpp 3.65 on OS/2 but now
they use "namespaces" in the code and because VAcpp 4.0 does not
support commandline compiling, they can't compile it on OS/2 anymore
(the project is simply too big for the VAcpp 4.0 workframe). On Linux
they use the Pentium optimized version of the GNU compiler and they
tried the same on OS/2. But unfortunately there is a problem in the
OS/2 port:

(Taken from http://www.goof.com/pcg/os2/#Bugs)

Known bugs:

emxomf now traps (sometimes?) when compiling with -g (debug) switch.
This is due to new format of debugging info (DWARF2). I do not know how
to fix this. Use A.OUT format (no -Zomf) for debugging and pmgdb. 

Solution: This happens because pgcc uses new stabs format (-gstabs+)
while emxomf understands only the standard stabs debugging info. I've
partialy fixed this by adding a tiny command-line preprocessor to gcc.
It scans argv[] and looks for both -Zomf and -g# where # is a number.
If it finds one, it replaces -g# by -gstabs#. This doesn't always help,
however. 
---

As you can see this is a limitation in EMX, we now have to find people
who are able to fix this (which will not be an easy task I think). We
are already in contact with Eberhard Mattes but we need more support.
If you think you are able to fix this, please get in contact with
Oliver Braun <[EMAIL PROTECTED]>. Please JUST reply if you really
think you can help StarDivision.

A StarOffice without debug informations can not be tested and if noone
can fix this limitation, Sun can not provide a new version for OS/2 !
So you see this is important for the future of StarOffice on OS/2.

Thanks for your support

Adrian Gschwend
@ OS/2 Netlabs
http://www.netlabs.org
===END FORWARDED MESSAGE===

We have released a.out (no -Zomf) till now, but for dll support (which
was rock solid with 1.04 in my tests) one should better move to -Zomf.
But then you can strip the binaries, so that no debugging code is left.
So the problem should be limited to the rare case that you must debug a
omf dll and depend on the stabs conversion to omf and dbg386. (Note you
can always try to build for debugging an a.out dll, but this is no
fun.)

Greets,

Arnd

More on compilers; Fwd:Compiling StarOffice and EGCS problems

[Arnd Hanses]

For the record (OS/2 compilers):

==BEGIN FORWARDED MESSAGE==
>Return-Path: <[EMAIL PROTECTED]>
>Delivered-To: [EMAIL PROTECTED]
>Message-Id: <[EMAIL PROTECTED]>
>Received: from trancentral ([212.74.44.49]) by mail.primeline.ch
>  (Post.Office MTA v3.5.1 release 219 ID# 0-61525U1000L100S0V35)
>  with SMTP id ch; Thu, 14 Oct 1999 20:37:07 +0200
>From: "Adrian Gschwend" <[EMAIL PROTECTED]>
>To: "XFree86 OS/2" <[EMAIL PROTECTED]>,
>"Buntspecht News" <[EMAIL PROTECTED]>,
>"Loren Bandiera" <[EMAIL PROTECTED]>,
>"Luc Van Bogaert" <[EMAIL PROTECTED]>,
>"Nick Marc" <[EMAIL PROTECTED]>, "OS/2 News Service" <[EMAIL PROTECTED]>,
>"Roman Eglin" <[EMAIL PROTECTED]>,
>"Steve Wendt" <[EMAIL PROTECTED]>,
>"VOICE Newsletter" <[EMAIL PROTECTED]>,
>"Warpcast" <[EMAIL PROTECTED]>
>Date: Thu, 14 Oct 1999 20:41:59 +0200 (CDT)
>X-Mailer: PMMail 2.00.1500 for OS/2 Warp 4.05
>MIME-Version: 1.0
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>Subject: [XFreeOS2] Compiling StarOffice and EGCS problems
>Sender: [EMAIL PROTECTED]
>Precedence: bulk
>Reply-To: [EMAIL PROTECTED]
>X-UIDL: 3be463aa0eeeff6daf34c66f47158dea
>

I talked to some people from StarOffice at Warpstock Europe and they
told me, that they have a serious problem with the OS/2 port of it.
Until now they used to compile the code with VAcpp 3.65 on OS/2 but now
they use "namespaces" in the code and because VAcpp 4.0 does not
support commandline compiling, they can't compile it on OS/2 anymore
(the project is simply too big for the VAcpp 4.0 workframe). On Linux
they use the Pentium optimized version of the GNU compiler and they
tried the same on OS/2. But unfortunately there is a problem in the
OS/2 port:

(Taken from http://www.goof.com/pcg/os2/#Bugs)

Known bugs:

emxomf now traps (sometimes?) when compiling with -g (debug) switch.
This is due to new format of debugging info (DWARF2). I do not know how
to fix this. Use A.OUT format (no -Zomf) for debugging and pmgdb. 

Solution: This happens because pgcc uses new stabs format (-gstabs+)
while emxomf understands only the standard stabs debugging info. I've
partialy fixed this by adding a tiny command-line preprocessor to gcc.
It scans argv[] and looks for both -Zomf and -g# where # is a number.
If it finds one, it replaces -g# by -gstabs#. This doesn't always help,
however. 
---

As you can see this is a limitation in EMX, we now have to find people
who are able to fix this (which will not be an easy task I think). We
are already in contact with Eberhard Mattes but we need more support.
If you think you are able to fix this, please get in contact with
Oliver Braun <[EMAIL PROTECTED]>. Please JUST reply if you really
think you can help StarDivision.

A StarOffice without debug informations can not be tested and if noone
can fix this limitation, Sun can not provide a new version for OS/2 !
So you see this is important for the future of StarOffice on OS/2.

Thanks for your support

Adrian Gschwend
@ OS/2 Netlabs
http://www.netlabs.org
===END FORWARDED MESSAGE===

We have released a.out (no -Zomf) till now, but for dll support (which
was rock solid with 1.04 in my tests) one should better move to -Zomf.
But then you can strip the binaries, so that no debugging code is left.
So the problem should be limited to the rare case that you must debug a
omf dll and depend on the stabs conversion to omf and dbg386. (Note you
can always try to build for debugging an a.out dll, but this is no
fun.)

Greets,

Arnd

Re: Overstrict ansi compliance?

[Lars Gullik Bjønnes]

"Arnd Hanses" <[EMAIL PROTECTED]> writes:

| On 14 Oct 1999 15:56:04 +0200, Jean-Marc Lasgouttes wrote:
| 
| If I don't mix C into too much, maybe this is a bit helpful:
| 
| >- static functions: I cannot declare them extern "C" too. 
| 
| In the context of functions, 'extern' is the mutually exclusive
| opposite of 'static', when the fn is internal to the module.

Does this hold on linkage specifications?

| But I think you can/should/must always write and use a 'global' or
| 'static' or 'static inline' C++ wrapper fn (with better readable ADT
| declaration, if you want) for an 'extern "C" {int foo(int)}' fn:
| 
|   typedef ADTfoo int;
|   extern "C" { int foo(int x) }
| 
|   static inline ADTfoo
|   wrap_foo(ADTfoo x)
|   {
|   return ( foo(x) )
|   }

This example does not solve the problem, and this solution should
never be needed.

| But why not use a 'static inline' C++ wrapper fn which disappears after
| optimizing. But then the compiler uses only the wrapper.

It is often this wrapper that cannot have C++ linkage...the problem
arises when passing pointer to functioncs that have "C" linkage.

The problem is more like:

extern "C" {
int foo(int(*)(int));
}

int bar(int);

You are now not allowed to pass bar to foo because of different
linkage, so:

extern "C" {
int bar_wrapper(int i) {
return bar(i);
}
}

Would solve the problem (I hope)

Lgb

Math formula labels sometimes doesnot work

[Stephane LOUISE]

Hello everyone,

As you migth expect i have a little problem with lyx 1.0.4 :

With some formulas i didn't manage to add a label.
eg:
   . 
 d x   1 dn
  = -   
  dt   n^3   dt

I didnot see anything like that in "known bugs", that's
why i send this mail.
general information:
lyx 1.0.4
OS: solaris 2.5.1
WS: Sun Ultra 30
compiler: gcc 2.8.1

I was wondering if i am the only one with this problem and
if there exists some workaround.

mata ne
-- 
luigi
mailto:[EMAIL PROTECTED]

problem compiling lyx 1.0.4

[mossop]

I've had some problems compiling lyx 1.0.4, when I run the 'make all'
command I get the following error:-

..
make[1]: Leaving directory `/home/mossop/local/src/lyx-1.0.4/po'
make[1]: Entering directory `/home/mossop/local/src/lyx-1.0.4/src'
g++ -c -g -O2 -I. -I. -I../images  -I/home/mossop/local/lib   
-I/usr/openwin/include -DPACKAGE=\"lyx\"
-DLOCALEDIR=\"/home/mossop/local/share/locale\" ../src/main.C
In file included from ../src/main.C:13:
../src/lyx_main.h:69: field `act_' has incomplete type
../src/filetools.h: In method `void FilePtr::do_open(const class LString
&, enum FilePtr::file_mode)':
In file included from ../src/main.C:16:
../src/filetools.h:97: warning: implicit declaration of function `int
fileno(...)'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/home/mossop/local/src/lyx-1.0.4/src'
make: *** [all] Error 1



This is on various sparcs/ultras running SunOS 5.5. I've tried fiddling
around a bit but to no avail. Any suggestions?

Re: Overstrict ansi compliance?

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> You are now not allowed to pass bar to foo because of different
Lars> linkage, so:

Lars> extern "C" { int bar_wrapper(int i) { return bar(i); } }

Lars> Would solve the problem (I hope)

I can confirm that it does (at least to some extent, since I have not
been able to check that it links and runs yet...

JMarc

LyX screen font bug

[Jörg Ziefle]

Hi there,

I think I've discovered a bug in LyX concerning the selection of screen
fonts: If you want to use certain ttf fonts from windows ( yes, I know...
;-) ) in LyX, you can set them temporarily in the options->screen fonts
menu, but not in the lyxrc

reason: most fonts have whitespaces in their name

example:

-ttf-times new roman-medium-r-normal-regular-0-0-0-0-p-0-iso8859-1
 ---

LyX fails to parse this:

LyX: Unknown tag `new' [...]
LyX: Unknown tag `roman' [...]

I hope this could help.

Regards,

Joerg

-- 
Jörg Ziefle   e-mail: [EMAIL PROTECTED]
Allmandring 20 D 35   FAX:  +49 (0)441 2443 39433
70569 Vaihingen   Tel.:+49 (0)177 4389721
PGP Fingerprint: D9 13 E5 1F 10 3F 85 C7  A7 8A 4F 9A B5 6F 5B 80

Re: Yet another cryptic error message

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> You are now suddenly using a more modern standard library and
Lars> there "sync" is a protected member, the right one to use is
Lars> "pubsync", the function that will get into effect when
Lars> MODERN_STL(?) is defined.

Is MODERN_STL defined for egcs? It is not with cxx, but I do not know
of a good test to define it.

However, I swear I got it to work earlier (before updating to your
path.h branch). Did you change something in configure?

JMarc

Re: Math formula labels sometimes doesnot work

[Jean-Marc Lasgouttes]

> "Stephane" == Stephane LOUISE <[EMAIL PROTECTED]> writes:

Stephane> Hello everyone, As you migth expect i have a little problem
Stephane> with lyx 1.0.4 :

Stephane> With some formulas i didn't manage to add a label. eg: . d x
Stephane> 1 dn  = -   dt n^3 dt

Stephane> I didnot see anything like that in "known bugs", that's why
Stephane> i send this mail. general information: lyx 1.0.4 OS: solaris
Stephane> 2.5.1 WS: Sun Ultra 30 compiler: gcc 2.8.1

Hello,

Could you send a file showing this?

JMarc

Re: LyX screen font bug

[Jean-Marc Lasgouttes]

> "Jörg" == Jörg Ziefle <[EMAIL PROTECTED]> writes:

Jörg> Hi there, I think I've discovered a bug in LyX concerning the
Jörg> selection of screen fonts: If you want to use certain ttf fonts
Jörg> from windows ( yes, I know... ;-) ) in LyX, you can set them
Jörg> temporarily in the options->screen fonts menu, but not in the
Jörg> lyxrc

Jörg> reason: most fonts have whitespaces in their name

Jörg> example:

Jörg>   -ttf-times new
Jörg> roman-medium-r-normal-regular-0-0-0-0-p-0-iso8859-1
Jörg> ---

In this case, you have to enclose the font name in "quotes".

JMarc

Final Installation cleanup patch

[Kayvan A. Sylvan]

Hi folks,

Here's the last install problem from the lyx-1.0.4 to lyx-1.1.1 rollover.

Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.25
diff -u -u -r1.25 ChangeLog
--- ChangeLog   1999/10/15 10:33:31 1.25
+++ ChangeLog   1999/10/15 21:14:54
@@ -1,7 +1,10 @@
-1999-10-15  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+1999-10-15  Kayvan A. Sylvan  <[EMAIL PROTECTED]>
 
+   * lib/reLyX/Makefile.am: add missing Verbatim.pm and
+   RelyxFigure.pm to EXTRA_DIST so they will be included in tarball.
+
* src/Makefile.am: add a definition for localedir, so that locales
-   are found after installation (Kayvan)
+   are found after installation.
 
 1999-10-14  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
Index: lib/reLyX/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/reLyX/Makefile.am,v
retrieving revision 1.2
diff -u -u -r1.2 Makefile.am
--- lib/reLyX/Makefile.am   1999/10/12 14:08:52 1.2
+++ lib/reLyX/Makefile.am   1999/10/15 21:14:55
@@ -8,6 +8,7 @@
 EXTRA_DIST = BUGS BasicLyX.pm CHANGES CleanTeX.pm LastLyX.pm MANIFEST \
MakePreamble.pm ReadCommands.pm RelyxTable.pm reLyX.pod \
reLyXmain.pl syntax.default test.ltx test.lyx reLyX.man \
+   RelyxFigure.pm Verbatim.pm \
$(LYXDISTDIRS)
 
 LIBINSTFILES = *.pm *.pl README BUGS CHANGES reLyX.pod syntax.default Text/*.pm


-- 
Kayvan Aghaiepour Sylvan  | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan |   | Robin Gregory (2/28/92)

bug report: lyx-1.0.3/4 crashing when including .eps figures

[Russ Ross]

lyx-1.0.3 and 1.0.4 consistently crash when I include
a .eps figure (generated using xfig).  Lyx dies when I
include it, but when I restart lyx and load the
emergency backup file, the figure is included
successfully and I don't have any more problems. 
Including additional figures repeats the problem.

I've attached a simple (3k) figure that causes the
problem on my machine.

I compiled lyx with CXXFLAGS='-O2'. I'm running on a
Mandrake 6.0 Linux installation using pgcc (gcc
--version gives "pgcc-2.91.66").  I did the 1.0.4
build today to confirm that the bug happened in the
latest version. I have xforms V0.89.

- Russ
__
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
 test.eps

Re: Name of Extended Features manual

[Arnd Hanses]

On Thu, 14 Oct 1999 11:51:07 -0700 (PDT), [EMAIL PROTECTED]
wrote:

>If you can come up with a better name, I think we'd all be happy to hear
>it. "Extended" was just the best we could come up with at the time.

"Special F."

AH

Re: Possible bug with 1.0.4...

[Jean-Marc Lasgouttes]

> "Rod" == Rod Pinna <[EMAIL PROTECTED]> writes:

Rod>   This message is in MIME format. The first part should be
Rod> readable text, while the remaining parts are likely unreadable
Rod> without MIME-aware tools. Send mail to
Rod> [EMAIL PROTECTED] for more info.

Rod> ---559023410-851401618-939949217=:8759 Content-Type: TEXT/PLAIN;
Rod> charset=US-ASCII

Rod> On 14 Oct 1999, Jean-Marc Lasgouttes wrote:

Rod> Jean-Marc,

Rod> Thanks for having a look at the problem. In the end, it turned
Rod> out the it was a "stupid user" error. The problem was that the
Rod> line:

Rod> Also, I've got the following in the body of the text
Rod> r_\textrm{wave}

Rod> should have been r_\mathrm{wave}. It seems once LyX comes across
Rod> the incorrect \textrm it gets a little confused. Anyway, I've
Rod> attached an example file (gzipped) which displays the behaviour.
Rod> If you load it, you should see the extra spaces between the
Rod> normal and subscript characters.

How did you input the formula? Mathed gives errors when reading it:

Line ~76: Math parse error: Expected {. Maybe you forgot to enclose an argument in {}
Line ~76: Math parse error: Unmatching braces
 Math Panic, expect problems!

You can enter such text directly with math text mode (type M-m m while
already in math mode).

JMarc