Re: multibyte support for lyx

[Kohtaro Hitomi]

On Sat, Dec 15, 2007 at 04:44:54PM +0900, [EMAIL PROTECTED] wrote:
 
 I would like to report that Korean as well as Japanese support for the
 lyx-1.1.3 is now possible. The binary package in the rpm format and the
 source package in the compressed atr format are available at
   ftp://stone.phys.pusan.ac.kr/pub/lyx-kr.

Thank you for making the patch. I'm japanese LyX user and waiting
for japanese patch for 1.1.3.

I got your patch, but couldn't make it. I got the following
message,

make[1]: Entering directory /home/kohtaro/tmp/lyx-1.1.3/src'
cd ..  autoheader
/usr/bin/autoheader: Symbol HAVE_XOPENIM' is not covered by
/usr/lib/autoconf/a
cconfig.h ./acconfig.h
make[1]: *** [stamp-h.in] Error 1
make[1]: Leaving directory /home/kohtaro/tmp/lyx-1.1.3/src'
make: *** [all-recursive] Error 1

Could you teach me how to make the program. I'm using redhat 5.3
on PC and redhat 6.0 on alpha. Both machine could not make.


-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kohtaro Hitomi
Kyoto Institute of Technology
Phone:+81-75-724-7262,  Fax:+81-75-724-7250

Unnecessary compiler warnings with lyx-1.1.4pre1

[Angus Leeming]

I'm compiling lyx-1.1.4pre1 using egcs-1.1.2 on Alpha with DU3.2. (OK, so I'm
lazy and haven't upgraded to a more recent version of Tru64 Unix)

Omitting the CXXFLAG -Wno-return-type leads to huge numbers of warning messages:
/usr/include/X11/Xlib.h:2481: warning: return-type of `XDrawImageString' defaults to 
`int'

Best wishes,
Angus

--
DR ANGUS LEEMING [EMAIL PROTECTED]
Department of Biological and Medical Systems
Imperial College
LONDON SW7 2BX

Tel. 0171 594 5186
Fax. 0171 584 6897

Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Hello,

today I tried to compile Lyx 1.1.3 with Sun's CC (C++ Workshop compiler
version 5.0) on Solaris 2.7. This compiler is said to comply to the ANSI
C++ standard. Unfortunately, I haven't been successful because of
several problems in the code. Could anybody please take a look at the
messages below? I only list the most important errors. There exists a
large number of warnings indicating, e.g. anachronisms in the C++ code.
If somebody is interested in a full listing of the compiler output
please do not hesitate to contact me.

Kind regards,

Michael

PS: Once I will be able to compile Lyx with Sun's Workshop compiler, I
will try to debug Lyx with the famous Purify run-time checker. One of my
students that has to write a long document with Lyx (I forced him to do
so :-) complains about a lot of crashes that seem to be related to the
usage of figures (especially subfigures) within a Lyx document. Purify
may help to detect the cause for these crashes (frankly speaking I am
not familiar with the Lyx nor do I have the time to fix bigger problems
on my own; I can only report problems)

+++

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/opt/local/include -I/usr/openwin/include +p
+w2 -compat=5 -g -c math_panel.C -o math_panel.o
"../../images/sqrt.xpm", line 2: Error: Multiple declaration for sqrt.
"math_panel.C", line 275: Error: Cannot return extern "C"
double(*)(double) from a function that should return char**.
"math_panel.C", line 301: Error: Formal argument 2 of type char** in
call to fl_set_pixmap_data(flobjs_*, char**) is being passed extern "C"
double(*)(double).

"figinset.C", line 257: Error: The function "kill" must have a
prototype.
"figinset.C", line 1727: Error: Unknown preprocessor directive."

"insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
not accessible from file level.

"filetools.C", line 325: Error: Formal argument 1 of type char* in call
to putenv(char*) is being passed const char*.

"lstrings.C", line 178: Error: Could not find a match for
std::count(const char*, const char*, const char).

"ImportNoweb.C", line 57: Error: Unknown preprocessor directive.

"LyXAction.C", line 614: Error: Unknown preprocessor directive.

"bmtable.C", line 46: Error: The function "calloc" must have a
prototype.
"bmtable.C", line 212: Error: The function "free" must have a prototype.

"support/lstrings.h", line 16: Error: Templates can only declare classes
or functions.
"support/lstrings.h", line 19: Error: size_t is not defined.
"support/lstrings.h", line 20: Error: "," expected instead of "const".
"support/lstrings.h", line 21: Error: A declaration was expected instead
of "while".
"support/lstrings.h", line 21: Error: ")" expected instead of "!=".
"support/lstrings.h", line 21: Error: Multiple declaration for count.
"support/lstrings.h", line 22: Error: A declaration was expected instead
of "return".
"support/lstrings.h", line 23: Error: A declaration was expected instead
of "}".

"layout.C", line 946: Error: Cannot use std::pairbool, int to
initialize std::pairbool, unsigned.

"lyx_cb.C", line 1116: Error: Unknown preprocessor directive.

"../src/lyx_main.C", line 139: Error: The function "signal" must have a
prototype.

"lyxfunc.C", line 391: Error: Unknown preprocessor directive.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==

Re: year end statistics

[Jean-Marc Lasgouttes]

 "Mate" == Mate Wierdl [EMAIL PROTECTED] writes:

Mate In case you are interested: Devel: = -rw-rw-r-- 1 lyx lyx
Mate 3296 Oct 31 1998 devel.old.subs

Mate wc -l devel.old.subs 134 devel.old.subs

Mate ezmlm-list ~/DEVEL/|wc -l 120

Interesting indeed. If we are 120 developpers, it should only take a
few days to finish this damn stuff. Or maybe the 14 who left this year
were the ones who could actually help?

Mate wc -l users.old.subs 354 users.old.subs

Mate ezmlm-list ~/USERS/|wc -l 414

That's a lot of people. Maybe I should consider saying fewer stupid
things, then...


And also the web page says: ``At least 264455 hits on this page.''. 

However, I'm not sure the counter began at 0...

JMarc

Re: Anybody tried to get the lyx-devel branch running on NT ?

[Roland Krause]

I have automake-1.4 from gtp.gnu.org and autoconf-1.13 from the same site. 
Got them yesterday. Maybe they arent working properly under Cygwin but I'd be
very surprised. 

Roland

On 16-Dec-99 Allan Rae wrote:
 
From your log of autogen.sh output it appears you need to upgrade to
 automake-1.4
 
 Allan. (ARRae)

Roland Krause
Visiting Research Associate - Center for Computational Mechanics
Washington University, Saint Louis
Roland Krause [EMAIL PROTECTED]

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

 Michael Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++
 Michael Workshop compiler version 5.0) on Solaris 2.7. This compiler
 Michael is said to comply to the ANSI C++ standard.
 
 Yes, we'd like to get LyX to compile there, but I do not have access to
 it.

Thank you very much for your quick response. I was afraid that you
consider my comments useless. If you like to I can recompile lyx from
time to time for you with Sun's CC. That's no big effort for me.

 First thing, could you get lyx 1.1.4pre1 and work from that? This
 would be much easier for us. Then send to the list the complete error
 log that you get.

OK, I downloaded this developer release. But certainly you won't like
the new compiler output. There seem to be many identical error messages,
mostly related to a missing ostream class (seems to be a namespace
problem (?)). Nevertheless, I attached the complete output to this mail.
I turned on all warnings and errors and requested full ANSI standard
conformance tests when running the compiler.

 I run purify on lyx from time to time, but since I do not know what to
 try, I do not find many things these days... Note that the figure code
 will be rewritten as soon as we can.

Nice to see that Purify is actually used to ensure software quality. I
wouldn't like to trust any piece of software that does not use a
run-time checker.

Happy bug fixing,

Michael

PS: Please contact me if I can do anything for you.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==
 compile_errors.gz

Re: Unnecessary compiler warnings with lyx-1.1.4pre1

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| I'm compiling lyx-1.1.4pre1 using egcs-1.1.2 on Alpha with DU3.2. (OK, so I'm
| lazy and haven't upgraded to a more recent version of Tru64 Unix)
| 
| Omitting the CXXFLAG -Wno-return-type leads to huge numbers of
| warning messages: 
| /usr/include/X11/Xlib.h:2481: warning: return-type of
| `XDrawImageString' defaults to `int' 

Does a "-fpermissive" work just as well?

what is the version string of your compiler?

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/opt/local/include 
-I/usr/openwin/include +p +w2 -compat=5 -g -c formula.C -o formula.o
"../../src/debug.h", line 65: Error: ostream is not defined.
"../../src/debug.h", line 68: Error: ostream is not defined.  

Try to add 

using std::ostream; 

right after #include iostream in src/support/DebugStream.h

If that does not work I think your compiler is wrong.

Most of the other errors comes because of this.

Hard to the real problems in all the noise.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

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

Lars CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
Lars -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g
Lars -c formula.C -o formula.o "../../src/debug.h", line 65: Error:
Lars ostream is not defined. "../../src/debug.h", line 68: Error:
Lars ostream is not defined.

Lars Try to add

Lars using std::ostream;

Lars right after #include iostream in src/support/DebugStream.h

Lars If that does not work I think your compiler is wrong.

Lars Most of the other errors comes because of this.

I already answered him to add a #include "support/LOstream.h" at the
beginning of debug.h. I think he is using STL string, and ostreams
are defined in lyxstring.h, so I did not see that I missed the header
in my last debug patch.

JMarc

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

| "figinset.C", line 257: Error: The function "kill" must have a
| prototype.

In my docs "kill" is not an ANSI C function and should not really be
in namespace std, but it seems that CC has put it there.
Add a
using std::kill;
and file a bug report to SUN.

| "figinset.C", line 1727: Error: Unknown preprocessor directive."

I was pretty sure that unknown preprocessor directives should be
ignored, but since I cannot find a reference I might be wrong...
We should make sure to wrap all the #warning dircetives then.

| "insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
| not accessible from file level.

This is one error I don't really understand.
 
| "filetools.C", line 325: Error: Formal argument 1 of type char* in call
| to putenv(char*) is being passed const char*.

file a bug report to SUN.

| "lstrings.C", line 178: Error: Could not find a match for
| std::count(const char*, const char*, const char).

Missing prototype in CC's libraries.
Easy to work around.

| "bmtable.C", line 46: Error: The function "calloc" must have a
| prototype.
| "bmtable.C", line 212: Error: The function "free" must have a
| prototype.

bmtable should really be put in a _C_ library and compiled with a _C_
compilator.

| 
| "support/lstrings.h", line 16: Error: Templates can only declare classes
| or functions.
| "support/lstrings.h", line 19: Error: size_t is not defined.

using std::size_t;
should probably fix that.

| "layout.C", line 946: Error: Cannot use std::pairbool, int to
| initialize std::pairbool, unsigned.

missing prototype in CC's lib. file a buf report.
(we can fix this with a static_cast)

| "../src/lyx_main.C", line 139: Error: The function "signal" must have a
| prototype.

using std::signal;

Lgb

Re: year end statistics

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| And also the web page says: ``At least 264455 hits on this page.''. 
| 
| However, I'm not sure the counter began at 0...

It did, but it some time ago... the number is actually on the low
side...

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| I already answered him to add a #include "support/LOstream.h" at the
| beginning of debug.h. I think he is using STL string, and ostreams
| are defined in lyxstring.h, so I did not see that I missed the header
| in my last debug patch.

I think iostream is required to includ ostream so I think LOstream.h
is a bit wrong.

I had some problems with L[IO]stream.h when trying out the gcu
libstd++ libarary.

Lgb

[triller@forwiss.uni-passau.de] Feedback from www.lyx.org

[Lars Gullik Bjønnes]

--- Start of forwarded message ---
Date: Thu, 16 Dec 1999 15:31:31 +0100
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Feedback from www.lyx.org
FROM: [EMAIL PROTECTED]


Triller Peter ([EMAIL PROTECTED]) entered the 
following feedback message on the LyX home page:


Hello, I found a minor flaw in lyx..
I just installed lyx 1.1.3 (and 1.1.2 for that matter) with
the following configure command on a Solaris 2.6 Sparc station
./configure --exec-prefix=/public/packages/text/lyx-1.1.3 
--prefix=/common/packages/text/lyx-1.1.3

But lyx doesn\'t come up
The reason for this is , it searches for it\'s scripts in the wrong places...
after doing a make install, we link the executables to /public/bin

when I startup lyx, it looks for ist\'s files in
\"/public/share/lyx\" and \"/public/packages/text/lyx-1.1.3/share/lyx\"
but the files were installed in \"/common/packages/text/lyx-1.1.3/share/lyx\"

I made a softlink so now it works, but I think this is a minor bug

Thnx and bye


Peter Triller

--- End of forwarded message ---

Re: year end statistics

[Mate Wierdl]

Or maybe the 14 who left this year were the ones who could
actually help?

Well, they may not have left---see the stats for the devel digest
list. 

Mate

listfiles

[Andre' Poenitz]

And another two responses from Lars missed...

Concerning 'lastfile.[Ch]'. I see no obvious reason to have an arbitrary
upper limit on the number of lastfiles. If anybody wants to have 50
files - let him have it. The menu is not in sync with the
implementation of LastFiles anyway...

If you drop this restriction, setNumberOfFiles is no more needed, the
last two lines of newFile could go, half of the while-condition in
readFile could go etc. I'd even say, lyxrc's \num_lastfile could go. 
Sometimes it's nice to be able to configure things. But how many users
ever will use this feature?

Bloat? Well. This is certainly some sort of religious question. If the
provided functionality is not *dearly* needed, my religion says it is
bloat. Having bits of code just because "it is nice and could perhaps be
useful later" is a thing that is difficult to accept for me.

Andre'

PS: We are talking about 2132 bytes in the unstripped and 512 bytes in
the stripped binary. This is about 1/4000 of the total. Yes, most people
think this is peanuts.

--
André Pönitz . [EMAIL PROTECTED]

Re: multibyte support for lyx

[Kohtaro Hitomi]

On Thu, Dec 16, 1999 at 09:48:32AM +0100, Jean-Marc Lasgouttes wrote:
 
 Check your versions of autoconf and automake. These should be 2.13 for
 autoconf and 1.4 for automake (use --version to get the version).
 
 JMarc

Thank you Jean-Marc. I updated autoconf and automake, but I can't
compile and got the same message. 


-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kohtaro Hitomi
Kyoto Institute of Technology
Phone:+81-75-724-7262,  Fax:+81-75-724-7250

Improper scope of centering command in 1.0.4, 1.1.2 1.1.3

[Vladan Lucic]

Exporting a LyX document containing a table in the LaTeX format
and importing the LaTeX file centers the text below the table.

The reason for this bug seems to be the improper understanding of the
scope of the centering command (that's how LyX centers a table) during
LaTeX file import: if the exported file is processed and displayed in the
usual way (latex and xdvi) everything is fine. Attached is the LaTeX file
that was exported from LyX and it shows the bug described above.

1.0.4, 1.1.2 and 1.1.3 versions show the same behavior, I run it on Linux
(kernel 2.0.36). 

If anyone needs to contact me, please send me the email directly; I'm not
on this mailing list.

Thanks

Vladan Lucic


%% This LaTeX-file was created by vladan Thu Dec 16 13:17:11 1999
%% LyX 1.0 (C) 1995-1999 by Matthias Ettrich and the LyX Team

%% Do not edit this file unless you know what you are doing.
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

\makeatletter


%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}

\makeatother

\begin{document}

Let's start

\vspace{0.3cm}
{\centering \begin{tabular}{|c|c|}
\hline 
aha 
hoho\\
\hline 
\hline 
auyee
eue\\
\hline 
\end{tabular}\par}
\vspace{0.3cm}

should not be centered



\end{document}

Re: Hebrew support for LyX

[Seak, Teng-Fong]

Shigeru Miyata wrote:

 "Seak, Teng-Fong" [EMAIL PROTECTED] wrote:

   Chinese (as well as Japanese and Korean) can also be written from right to
  left, even though this isn't very common nowadays.  Actually, in tradition,
  Chinese is written from top to the bottom, then from right to left.  But I
  don't think Latex is able to support this :-)

 Theoretically speaking it is of course possible.  However, dimensions
 [deleted]
 TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian)
 primitives.

 Actually, there's another possible solution (or even simpler): rotate all
characters to the left by 90° :-)  but only if it's supported by LaTeX.  If this is
supported, we just need to type in LTR then TTB and after rotation, the text will be
TTB then RTL.

 But I'm not sure if LaTeX supports already double-byte encoding, so I'm not
going to ask this question in the newsgroup for the moment.

 Seak

Re: Internationalization and cvs

[Seak, Teng-Fong]

Andre' Poenitz wrote:

 Concerning the multi-byte encoding: We should have a discussion
 whether
 it is sensible to use Unicode internally. The world is changing and
 last
 years' arguments won't fit anymore.

 May I know what this "last year's argument" is?  I joined this list
for less than one month.

 We could get rid of almost all of the encoding stuff at the price of
 double sized buffers plus quite a bit of work. But in the end thing
 would be much simpler

 It might have other advantages.  Eg, lastest versions of Windows
use Unicode internally and LyX is ported to windows, using Unicode
inside LyX perhaps could help i18n/l10n (if this is possible with
Cygnus) work also
for windows port more "natively"?  That is, windows doesn't have to
translate a menu string from a particular encoding to Unicode before
displaying it.

Re: multibyte support for lyx

[ChangGil Han]

You have to add the following line,
  "#undef HAVE_XOPENIM"
 somewhere in "acconfig.h". I forgot to
include this in the patch, sorry.

Re: multibyte support for lyx

[Kohtaro Hitomi]

On Thu, Dec 16, 1999 at 05:58:00PM -0800, ChangGil Han wrote:
 You have to add the following line,
   "#undef HAVE_XOPENIM"
  somewhere in "acconfig.h". I forgot to
 include this in the patch, sorry.

Thank you ChangGil, I can compile. I'll send you a report later. 

Anyway can I place a link to your ftp site from my web pege
(http://www.hiei.kit.ac.jp/~hitomi/lyx)?


-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kohtaro Hitomi
Kyoto Institute of Technology
Phone:+81-75-724-7262,  Fax:+81-75-724-7250

Re: multibyte support for lyx

[Kohtaro Hitomi]

On Sat, Dec 15, 2007 at 04:44:54PM +0900, [EMAIL PROTECTED] wrote:
> 
> I would like to report that Korean as well as Japanese support for the
> lyx-1.1.3 is now possible. The binary package in the rpm format and the
> source package in the compressed atr format are available at
>   ftp://stone.phys.pusan.ac.kr/pub/lyx-kr.

Thank you for making the patch. I'm japanese LyX user and waiting
for japanese patch for 1.1.3.

I got your patch, but couldn't make it. I got the following
message,

make[1]: Entering directory /home/kohtaro/tmp/lyx-1.1.3/src'
cd .. && autoheader
/usr/bin/autoheader: Symbol HAVE_XOPENIM' is not covered by
/usr/lib/autoconf/a
cconfig.h ./acconfig.h
make[1]: *** [stamp-h.in] Error 1
make[1]: Leaving directory /home/kohtaro/tmp/lyx-1.1.3/src'
make: *** [all-recursive] Error 1

Could you teach me how to make the program. I'm using redhat 5.3
on PC and redhat 6.0 on alpha. Both machine could not make.


-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kohtaro Hitomi
Kyoto Institute of Technology
Phone:+81-75-724-7262,  Fax:+81-75-724-7250

Unnecessary compiler warnings with lyx-1.1.4pre1

[Angus Leeming]

I'm compiling lyx-1.1.4pre1 using egcs-1.1.2 on Alpha with DU3.2. (OK, so I'm
lazy and haven't upgraded to a more recent version of Tru64 Unix)

Omitting the CXXFLAG -Wno-return-type leads to huge numbers of warning messages:
/usr/include/X11/Xlib.h:2481: warning: return-type of `XDrawImageString' defaults to 
`int'

Best wishes,
Angus

--
DR ANGUS LEEMING <[EMAIL PROTECTED]>
Department of Biological and Medical Systems
Imperial College
LONDON SW7 2BX

Tel. 0171 594 5186
Fax. 0171 584 6897

Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Hello,

today I tried to compile Lyx 1.1.3 with Sun's CC (C++ Workshop compiler
version 5.0) on Solaris 2.7. This compiler is said to comply to the ANSI
C++ standard. Unfortunately, I haven't been successful because of
several problems in the code. Could anybody please take a look at the
messages below? I only list the most important errors. There exists a
large number of warnings indicating, e.g. anachronisms in the C++ code.
If somebody is interested in a full listing of the compiler output
please do not hesitate to contact me.

Kind regards,

Michael

PS: Once I will be able to compile Lyx with Sun's Workshop compiler, I
will try to debug Lyx with the famous Purify run-time checker. One of my
students that has to write a long document with Lyx (I forced him to do
so :-) complains about a lot of crashes that seem to be related to the
usage of figures (especially subfigures) within a Lyx document. Purify
may help to detect the cause for these crashes (frankly speaking I am
not familiar with the Lyx nor do I have the time to fix bigger problems
on my own; I can only report problems)

+++

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/opt/local/include -I/usr/openwin/include +p
+w2 -compat=5 -g -c math_panel.C -o math_panel.o
"../../images/sqrt.xpm", line 2: Error: Multiple declaration for sqrt.
"math_panel.C", line 275: Error: Cannot return extern "C"
double(*)(double) from a function that should return char**.
"math_panel.C", line 301: Error: Formal argument 2 of type char** in
call to fl_set_pixmap_data(flobjs_*, char**) is being passed extern "C"
double(*)(double).

"figinset.C", line 257: Error: The function "kill" must have a
prototype.
"figinset.C", line 1727: Error: Unknown preprocessor directive."

"insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
not accessible from file level.

"filetools.C", line 325: Error: Formal argument 1 of type char* in call
to putenv(char*) is being passed const char*.

"lstrings.C", line 178: Error: Could not find a match for
std::count<>(const char*, const char*, const char).

"ImportNoweb.C", line 57: Error: Unknown preprocessor directive.

"LyXAction.C", line 614: Error: Unknown preprocessor directive.

"bmtable.C", line 46: Error: The function "calloc" must have a
prototype.
"bmtable.C", line 212: Error: The function "free" must have a prototype.

"support/lstrings.h", line 16: Error: Templates can only declare classes
or functions.
"support/lstrings.h", line 19: Error: size_t is not defined.
"support/lstrings.h", line 20: Error: "," expected instead of "const".
"support/lstrings.h", line 21: Error: A declaration was expected instead
of "while".
"support/lstrings.h", line 21: Error: ")" expected instead of "!=".
"support/lstrings.h", line 21: Error: Multiple declaration for count.
"support/lstrings.h", line 22: Error: A declaration was expected instead
of "return".
"support/lstrings.h", line 23: Error: A declaration was expected instead
of "}".

"layout.C", line 946: Error: Cannot use std::pair to
initialize std::pair.

"lyx_cb.C", line 1116: Error: Unknown preprocessor directive.

"../src/lyx_main.C", line 139: Error: The function "signal" must have a
prototype.

"lyxfunc.C", line 391: Error: Unknown preprocessor directive.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==

Re: year end statistics

[Jean-Marc Lasgouttes]

> "Mate" == Mate Wierdl <[EMAIL PROTECTED]> writes:

Mate> In case you are interested: Devel: = -rw-rw-r-- 1 lyx lyx
Mate> 3296 Oct 31 1998 devel.old.subs

Mate> wc -l devel.old.subs 134 devel.old.subs

Mate> ezmlm-list ~/DEVEL/|wc -l 120

Interesting indeed. If we are 120 developpers, it should only take a
few days to finish this damn stuff. Or maybe the 14 who left this year
were the ones who could actually help?

Mate> wc -l users.old.subs 354 users.old.subs

Mate> ezmlm-list ~/USERS/|wc -l 414

That's a lot of people. Maybe I should consider saying fewer stupid
things, then...


And also the web page says: ``At least 264455 hits on this page.''. 

However, I'm not sure the counter began at 0...

JMarc

Re: Anybody tried to get the lyx-devel branch running on NT ?

[Roland Krause]

I have automake-1.4 from gtp.gnu.org and autoconf-1.13 from the same site. 
Got them yesterday. Maybe they arent working properly under Cygwin but I'd be
very surprised. 

Roland

On 16-Dec-99 Allan Rae wrote:
> 
>>From your log of autogen.sh output it appears you need to upgrade to
> automake-1.4
> 
> Allan. (ARRae)

Roland Krause
Visiting Research Associate - Center for Computational Mechanics
Washington University, Saint Louis
Roland Krause <[EMAIL PROTECTED]>

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

> Michael> Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++
> Michael> Workshop compiler version 5.0) on Solaris 2.7. This compiler
> Michael> is said to comply to the ANSI C++ standard.
> 
> Yes, we'd like to get LyX to compile there, but I do not have access to
> it.

Thank you very much for your quick response. I was afraid that you
consider my comments useless. If you like to I can recompile lyx from
time to time for you with Sun's CC. That's no big effort for me.

> First thing, could you get lyx 1.1.4pre1 and work from that? This
> would be much easier for us. Then send to the list the complete error
> log that you get.

OK, I downloaded this developer release. But certainly you won't like
the new compiler output. There seem to be many identical error messages,
mostly related to a missing ostream class (seems to be a namespace
problem (?)). Nevertheless, I attached the complete output to this mail.
I turned on all warnings and errors and requested full ANSI standard
conformance tests when running the compiler.

> I run purify on lyx from time to time, but since I do not know what to
> try, I do not find many things these days... Note that the figure code
> will be rewritten as soon as we can.

Nice to see that Purify is actually used to ensure software quality. I
wouldn't like to trust any piece of software that does not use a
run-time checker.

Happy bug fixing,

Michael

PS: Please contact me if I can do anything for you.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==
 compile_errors.gz

Re: Unnecessary compiler warnings with lyx-1.1.4pre1

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| I'm compiling lyx-1.1.4pre1 using egcs-1.1.2 on Alpha with DU3.2. (OK, so I'm
| lazy and haven't upgraded to a more recent version of Tru64 Unix)
| 
| Omitting the CXXFLAG -Wno-return-type leads to huge numbers of
| warning messages: 
| /usr/include/X11/Xlib.h:2481: warning: return-type of
| `XDrawImageString' defaults to `int' 

Does a "-fpermissive" work just as well?

what is the version string of your compiler?

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/opt/local/include 
-I/usr/openwin/include +p +w2 -compat=5 -g -c formula.C -o formula.o
"../../src/debug.h", line 65: Error: ostream is not defined.
"../../src/debug.h", line 68: Error: ostream is not defined.  

Try to add 

using std::ostream; 

right after #include  in src/support/DebugStream.h

If that does not work I think your compiler is wrong.

Most of the other errors comes because of this.

Hard to the real problems in all the noise.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

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

Lars> CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
Lars> -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g
Lars> -c formula.C -o formula.o "../../src/debug.h", line 65: Error:
Lars> ostream is not defined. "../../src/debug.h", line 68: Error:
Lars> ostream is not defined.

Lars> Try to add

Lars> using std::ostream;

Lars> right after #include  in src/support/DebugStream.h

Lars> If that does not work I think your compiler is wrong.

Lars> Most of the other errors comes because of this.

I already answered him to add a #include "support/LOstream.h" at the
beginning of debug.h. I think he is using STL string, and ostreams
are defined in lyxstring.h, so I did not see that I missed the header
in my last debug patch.

JMarc

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| "figinset.C", line 257: Error: The function "kill" must have a
| prototype.

In my docs "kill" is not an ANSI C function and should not really be
in namespace std, but it seems that CC has put it there.
Add a
using std::kill;
and file a bug report to SUN.

| "figinset.C", line 1727: Error: Unknown preprocessor directive."

I was pretty sure that unknown preprocessor directives should be
ignored, but since I cannot find a reference I might be wrong...
We should make sure to wrap all the #warning dircetives then.

| "insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
| not accessible from file level.

This is one error I don't really understand.
 
| "filetools.C", line 325: Error: Formal argument 1 of type char* in call
| to putenv(char*) is being passed const char*.

file a bug report to SUN.

| "lstrings.C", line 178: Error: Could not find a match for
| std::count<>(const char*, const char*, const char).

Missing prototype in CC's libraries.
Easy to work around.

| "bmtable.C", line 46: Error: The function "calloc" must have a
| prototype.
| "bmtable.C", line 212: Error: The function "free" must have a
| prototype.

bmtable should really be put in a _C_ library and compiled with a _C_
compilator.

| 
| "support/lstrings.h", line 16: Error: Templates can only declare classes
| or functions.
| "support/lstrings.h", line 19: Error: size_t is not defined.

using std::size_t;
should probably fix that.

| "layout.C", line 946: Error: Cannot use std::pair to
| initialize std::pair.

missing prototype in CC's lib. file a buf report.
(we can fix this with a static_cast)

| "../src/lyx_main.C", line 139: Error: The function "signal" must have a
| prototype.

using std::signal;

Lgb

Re: year end statistics

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| And also the web page says: ``At least 264455 hits on this page.''. 
| 
| However, I'm not sure the counter began at 0...

It did, but it some time ago... the number is actually on the low
side...

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| I already answered him to add a #include "support/LOstream.h" at the
| beginning of debug.h. I think he is using STL string, and ostreams
| are defined in lyxstring.h, so I did not see that I missed the header
| in my last debug patch.

I think iostream is required to includ ostream so I think LOstream.h
is a bit wrong.

I had some problems with L[IO]stream.h when trying out the gcu
libstd++ libarary.

Lgb

[triller@forwiss.uni-passau.de] Feedback from www.lyx.org

[Lars Gullik Bjønnes]

--- Start of forwarded message ---
Date: Thu, 16 Dec 1999 15:31:31 +0100
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Feedback from www.lyx.org
FROM: [EMAIL PROTECTED]


Triller Peter ([EMAIL PROTECTED]) entered the 
following feedback message on the LyX home page:


Hello, I found a minor flaw in lyx..
I just installed lyx 1.1.3 (and 1.1.2 for that matter) with
the following configure command on a Solaris 2.6 Sparc station
./configure --exec-prefix=/public/packages/text/lyx-1.1.3 
--prefix=/common/packages/text/lyx-1.1.3

But lyx doesn\'t come up
The reason for this is , it searches for it\'s scripts in the wrong places...
after doing a make install, we link the executables to /public/bin

when I startup lyx, it looks for ist\'s files in
\"/public/share/lyx\" and \"/public/packages/text/lyx-1.1.3/share/lyx\"
but the files were installed in \"/common/packages/text/lyx-1.1.3/share/lyx\"

I made a softlink so now it works, but I think this is a minor bug

Thnx and bye


Peter Triller

--- End of forwarded message ---

Re: year end statistics

[Mate Wierdl]

Or maybe the 14 who left this year were the ones who could
actually help?

Well, they may not have left---see the stats for the devel digest
list. 

Mate

listfiles

[Andre' Poenitz]

And another two responses from Lars missed...

Concerning 'lastfile.[Ch]'. I see no obvious reason to have an arbitrary
upper limit on the number of lastfiles. If anybody wants to have 50
files - let him have it. The menu is not in sync with the
implementation of LastFiles anyway...

If you drop this restriction, setNumberOfFiles is no more needed, the
last two lines of newFile could go, half of the while-condition in
readFile could go etc. I'd even say, lyxrc's \num_lastfile could go. 
Sometimes it's nice to be able to configure things. But how many users
ever will use this feature?

Bloat? Well. This is certainly some sort of religious question. If the
provided functionality is not *dearly* needed, my religion says it is
bloat. Having bits of code just because "it is nice and could perhaps be
useful later" is a thing that is difficult to accept for me.

Andre'

PS: We are talking about 2132 bytes in the unstripped and 512 bytes in
the stripped binary. This is about 1/4000 of the total. Yes, most people
think this is peanuts.

--
André Pönitz . [EMAIL PROTECTED]

Re: multibyte support for lyx

[Kohtaro Hitomi]

On Thu, Dec 16, 1999 at 09:48:32AM +0100, Jean-Marc Lasgouttes wrote:
> 
> Check your versions of autoconf and automake. These should be 2.13 for
> autoconf and 1.4 for automake (use --version to get the version).
> 
> JMarc

Thank you Jean-Marc. I updated autoconf and automake, but I can't
compile and got the same message. 


-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kohtaro Hitomi
Kyoto Institute of Technology
Phone:+81-75-724-7262,  Fax:+81-75-724-7250

Improper scope of centering command in 1.0.4, 1.1.2 & 1.1.3

[Vladan Lucic]

Exporting a LyX document containing a table in the LaTeX format
and importing the LaTeX file centers the text below the table.

The reason for this bug seems to be the improper understanding of the
scope of the centering command (that's how LyX centers a table) during
LaTeX file import: if the exported file is processed and displayed in the
usual way (latex and xdvi) everything is fine. Attached is the LaTeX file
that was exported from LyX and it shows the bug described above.

1.0.4, 1.1.2 and 1.1.3 versions show the same behavior, I run it on Linux
(kernel 2.0.36). 

If anyone needs to contact me, please send me the email directly; I'm not
on this mailing list.

Thanks

Vladan Lucic


%% This LaTeX-file was created by  Thu Dec 16 13:17:11 1999
%% LyX 1.0 (C) 1995-1999 by Matthias Ettrich and the LyX Team

%% Do not edit this file unless you know what you are doing.
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

\makeatletter


%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}

\makeatother

\begin{document}

Let's start

\vspace{0.3cm}
{\centering \begin{tabular}{|c|c|}
\hline 
aha &
hoho\\
\hline 
\hline 
auyee&
eue\\
\hline 
\end{tabular}\par}
\vspace{0.3cm}

should not be centered



\end{document}

Re: Hebrew support for LyX

[Seak, Teng-Fong]

Shigeru Miyata wrote:

> "Seak, Teng-Fong" <[EMAIL PROTECTED]> wrote:
>
> >  Chinese (as well as Japanese and Korean) can also be written from right to
> > left, even though this isn't very common nowadays.  Actually, in tradition,
> > Chinese is written from top to the bottom, then from right to left.  But I
> > don't think Latex is able to support this :-)
>
> Theoretically speaking it is of course possible.  However, dimensions
> [deleted]
> TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian)
> primitives.

 Actually, there's another possible solution (or even simpler): rotate all
characters to the left by 90° :-)  but only if it's supported by LaTeX.  If this is
supported, we just need to type in LTR then TTB and after rotation, the text will be
TTB then RTL.

 But I'm not sure if LaTeX supports already double-byte encoding, so I'm not
going to ask this question in the newsgroup for the moment.

 Seak

Re: Internationalization and cvs

[Seak, Teng-Fong]

Andre' Poenitz wrote:

> Concerning the multi-byte encoding: We should have a discussion
> whether
> it is sensible to use Unicode internally. The world is changing and
> last
> years' arguments won't fit anymore.

 May I know what this "last year's argument" is?  I joined this list
for less than one month.

> We could get rid of almost all of the encoding stuff at the price of
> double sized buffers plus quite a bit of work. But in the end thing
> would be much simpler

 It might have other advantages.  Eg, lastest versions of Windows
use Unicode internally and LyX is ported to windows, using Unicode
inside LyX perhaps could help i18n/l10n (if this is possible with
Cygnus) work also
for windows port more "natively"?  That is, windows doesn't have to
translate a menu string from a particular encoding to Unicode before
displaying it.

Re: multibyte support for lyx

[ChangGil Han]

You have to add the following line,
  "#undef HAVE_XOPENIM"
 somewhere in "acconfig.h". I forgot to
include this in the patch, sorry.

Re: multibyte support for lyx

[Kohtaro Hitomi]

On Thu, Dec 16, 1999 at 05:58:00PM -0800, ChangGil Han wrote:
> You have to add the following line,
>   "#undef HAVE_XOPENIM"
>  somewhere in "acconfig.h". I forgot to
> include this in the patch, sorry.

Thank you ChangGil, I can compile. I'll send you a report later. 

Anyway can I place a link to your ftp site from my web pege
(http://www.hiei.kit.ac.jp/~hitomi/lyx)?


-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kohtaro Hitomi
Kyoto Institute of Technology
Phone:+81-75-724-7262,  Fax:+81-75-724-7250