Re: 3026 public symbol exports in LyX global name space (wa: Re: LaTeX file handling)
On 6 Sep 1999 06:13:13 +0900, [EMAIL PROTECTED] wrote: "Arnd Hanses" [EMAIL PROTECTED] wrote: Going up the stack 'till main() I'm now convinced that _heapset(9) produces on my box a self-induced crash (heap corruption) in emx libs. I'm unsure why this happens, it shouldn't, I think (or did I forget misunderstand it's function: Heap freespace setting to specified value?). Is this reproducible? I may be wrong, but once unused heaps are filled with non-zero values it is not necessarily harmful to receive _HEAPBADNODE with _heapchk(). [...] Notice _heap* functions do not set errno. In fact don't receive anything, simply crashing, core complete garbage. Maybe, I should check libs of different patch levels, report behaviour to emx list. If I'm not too lazy... Probably errno thingy is more important. Sure! A kingdom for a clue :) Tracing down looks like much work ... :( Regards, Arnd
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
"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. 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? JMarc
lyx 0.10
Hi, I wish to know if lyx 0.10 and 0.12 are year 2000 compliant. Cany you answer it? Thanks, -- Oscar Guell Perez University of Catalonia Tel 93 401 73 27 [EMAIL PROTECTED] http://www.lsi.upc.es/~oskar
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: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "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. if fprintf works we can switch to that without problems (in 1.0.x) In 1.1.x we will not use C i/o. | 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? No, it should not be...but if there is a bug in the library.. Lgb
xforms 0.89
Hava anyone been able to compile and run LyX with xfroms 0.89? I get a (gdb) run Starting program: /home/larsbj/Development/lyx/src/lyx BadDrawable (invalid Pixmap or Window parameter) when trying. It seems that it crashes in the initialization of the xpm part of the lib. (I don't link with libXpm, I commented out the one line in mathed/math_symbols.c that needs it) I am not quite sure what is happening. Any input? Lgb
Re: xforms 0.89
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Hava anyone been able to compile and run LyX with xfroms 0.89? Lars I get a (gdb) run Starting program: Lars /home/larsbj/Development/lyx/src/lyx BadDrawable (invalid Pixmap Lars or Window parameter) Lars when trying. It seems that it crashes in the initialization of Lars the xpm part of the lib. Do you build inside the development tree? I get that with 0.88.1 because I build outside the dev tree. In this case, when starting lyx as 'src/lyx', the code which finds the library path gets confused (some of-by-one error in string handling, I believe). It did not have time to fix it, but I think the X error is due to the fact that some pixmap is not found correctly, and is not related to 0.89. JMarc
Re: xforms 0.89
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Do you build inside the development tree? I get that with 0.88.1
| because I build outside the dev tree. In this case, when starting lyx
| as 'src/lyx', the code which finds the library path gets confused
| (some of-by-one error in string handling, I believe).
I build inside the developmen tree.
I can't see the off-by-one error.
from the trace:
#10 0x80dc110 in setPixmap (obj=0x81cf108, action=4, buttonwidth=30,
height=30)
at toolbar.C:173
173 fl_set_pixmapbutton_file(obj,
fullname.c_str());
(gdb) p fullname
$1 = {static npos = 4294967295, rep = 0x81cf348}
(gdb) p fullname.rep
$2 = (Srep *) 0x81cf348
(gdb) p *fullname.rep
$3 = {static xtra = optimized out, sz = 55, ref = 1, res = 59,
s = 0x81cf398 "/home/larsbj/Development/lyx/lib/images/buffer-open.xpm"}
and
[larsbj@cube larsbj]$ ls /home/larsbj/Development/lyx/lib/images/buffer-open.xpm
/home/larsbj/Development/lyx/lib/images/buffer-open.xpm
So I can't see any problems there.
Lgb
Re: xforms 0.89
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Do you build inside the development tree? I get that with 0.88.1 Lars | because I build outside the dev tree. In this case, when Lars starting lyx | as 'src/lyx', the code which finds the library Lars path gets confused | (some of-by-one error in string handling, I Lars believe). Lars I build inside the developmen tree. I can't see the off-by-one Lars error. Do you use the static or dynamic xforms library? One has libxpm built-in but with the other, it might happen that you have a dynamic libxpm with version !=3.4k (the one used by xforms) and that there is a binary incompatibility... I'm not sure that what I wrote makes sense, but... JMarc
Re: \title[foo]{bar} et al.
On Fri, 3 Sep 1999, Amir Karger wrote:
Question for the latex gurus in the audience.
One popular complaint about lyx 1.0 is that you can't get the equivalent of
\section[short]{long section title}.
[...]
Hi Amir,
I posted exactly the same trick some months ago to get short caption
entries in the listofwhatever. It is easily generalized to headings.
From [EMAIL PROTECTED] Mon Sep 6 17:56:21 1999
Date: Thu, 15 Apr 1999 10:32:01 +0200 (MESZ)
From: Fred Hucht [EMAIL PROTECTED]
To: LyX Development Mailing List [EMAIL PROTECTED]
Subject: Re: clip figures script... and some more tricks
Hi,
one alternative is to use TeX to turn clipping on. I use
%--
\makeatletter
\newcommand{\Clip}[1]{%
\let\zztmp=\includegraphics%
\def\includegraphics{\Gin@cliptrue\Gin@i}%
#1%
\let\includegraphics=\zztmp%
}
\makeatother
%--
and then put a '\Clip{' before and a '}' after the tobeclipped
graphics. To clip all graphics use
%--
\makeatletter
\def\includegraphics{\Gin@cliptrue\Gin@i}
\makeatother
%--
in the preamble.
Other TeX stuff I use include the handy
%--
\newcommand{\C}[1]{{}} % Comment
%--
to comment out whole blocks of LyX text.
Also useful is the combo
%--
\makeatletter
\newcommand{\CapListEntry}[1]{\def\@CapListEntryFlag{1}\def\@CapListEntryText{#1}}
\def\@CapListEntryFlag{0}
\def\caption#1{\refstepcounter\@captype%
\ifodd\@CapListEntryFlag%
\@dblarg{\@caption\@captype}[\@CapListEntryText]{#1}%
\def\@CapListEntryFlag{0}%
\else%
\@dblarg{\@caption\@captype}{#1}%
\fi}
\makeatother
%--
to use the optional argument or caption, i.e. allow different text in
the list of figures/tables. CapListEntry can be made a LyX environment
by adding
# --
# Caption style definition
Style CapListEntry
MarginFirst_Dynamic
LatexType Command
LatexName CapListEntry
NeedProtect 1
LabelSep x
ParSkip 0
TopSep0
Align Block
AlignPossible Block, Left
LabelType Static
LabelString Entry:
Font
SizeSmall
EndFont
End
# --
to ~/.lyx/layouts/stdlayouts.inc.
Then, just put the CapListEntry environment before tha caption
environment and...
have fun,
Fred
Fred Hucht, Institute of Theoretical Physics, University of Duisburg, Germany
Email: [EMAIL PROTECTED] http://www.thp.Uni-Duisburg.DE/
"Der Koerper der algebraischen Zahlen ist kein algebraischer Zahlkoerper"
(E. Landau, Zahlentheorie (1927), Satz 718)
Re: Warning! POSIX does not buy you much...
Duncan Simpson [EMAIL PROTECTED] writes: Ok, this is known. But what has this _really_ to do with the Subject? | According to my man page strcasecmp is conforming to BSD 4.3 (and | all unicies | I have seen so far, inclduign SunOS). AFAIK GNU libc 2.1 is | conforming to ANSI | and POSIX but also includes common extensions, like mmap, lstat, setrlimit, | snprintf, select, fileno, *BSD sockets and whole bunch of other | stuff that is | endemic in un*x source code and supported everywhere with very few | exceptions. | I can use fdopen in POSIX programs. There are also some things that | only exist | in glibc, and linux libc 5, like strfry(3) and memfrob(3), which are | presumably included for hack value. | | The average punter, and Un*x programmer, is not aware of how little POSIX | gives him. As soon as you prevent a remote root exploit by using | snprintf you | have violated POSIX And you don't know if you prog will compile on a system not running gnu libs. |---and of course by doing any networking and using | select(2) you have violated POSIX anyway. All internationalisation is beyond | the POSIX standard too. Not quite true, check man setlocale: CONFORMING TO ANSI C, POSIX.1 | BTW word2x has a source file that gives you strcasecmp and | strncasecmp if you | do not have them. LyX can steal it by GPL magic, which might GPL LyX on a | technicality. I think LyX is already GPLed anyway :-) We do not want to use strcasecmp, and in LyX 1.1.x we are getting rid of it. (using more native C++ constructs instead.) And yes, LyX is GPL, and has always been. (excetp for the very beginning perhaps) Lgb
[Andrew S. Townley atownley@informix.com] Re: new prerelease LyX-1.0.4pre6
I have forwarded your msg to the devel lyx. I am sure our DocBook person will answer your questions. Lgb --- Start of forwarded message --- Message-Id: [EMAIL PROTECTED] Date: Mon, 06 Sep 1999 18:10:16 + From: "Andrew S. Townley" [EMAIL PROTECTED] To: Lars Gullik =?iso-8859-1?Q?Bj=F8nnes?= [EMAIL PROTECTED] Subject: Re: new prerelease LyX-1.0.4pre6 References: [EMAIL PROTECTED] Hi. I have been using lyx for several months now (again, actually. I had used it a long time ago as well), but the main thing that I am using it for right now is to generate SGML for publication in both PS and HTML formats. I am very pleased to see how well the DocBook support is progressing, but I was wondering about a couple of things: 1) In the finished DocBook support, will we be able to use tables and images in lyx and have them appear appropriately in both the PS and HTML output? In playing with the DocBook support, I noticed that the tables were at least available, but when they were translated to HTML, they didn't have the appropriate HTML formatting. 2) Images were really strange: if I used formats that LyX understands, they aren't displayable by the browsers. Is there some sort of a plan to be able to support more image formats and have LyX deal with the appropriate conversions when the SGML is exported? My goal is to be able to use LyX for the creation of Functional Specifications as well as user documentation for some of our internally developed tools. Right now, I don't have a really good tool that will allow me to quickly create documents that are publishable in HTML but that also provide a really good version for printing. If you're not the correct person to ask, I'm sorry to bother you. With each new release of the DocBook-aware LyX, I'm just getting more hopeful... :) Thanks for your time, ast "Lars Gullik Bjønnes" wrote: -BEGIN PGP SIGNED MESSAGE- Docbook support is not quite finished so we will most likely have at least one more prerelease before 1.0.4 proper. Changes in this pre: - - better scroll-wheel support (found on certain mice) - - custom-pagesize support is better. (really a bug) - - short index label. - - latex run algorithms log parsing changed. (test this please) Also a couple of bugs, fixed. As alway with prereleases be careful. Make a backup of your important documents. Get the prerelease from: ftp://ftp.lyx.org/pub/lyx/stable/lyx-1.0.4pre6.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/lyx-1.0.4pre6.tar.gz ftp://la1ad.uio.no/pub/lyx/lyx-1.0.4pre6.tar.gz Lgb -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Comment: Processed by Mailcrypt 3.5.2, an Emacs/PGP interface Charset: noconv iQCVAwUBN8S2mXfblV6DEjKhAQG9XgP/Q63UHFXTIq5FymBhMJi1IYuQvICiOpFf PTzaLHI2e2QkfNySMH/fJNZ47kVsujkTuy/ri1Ou/+dYNF6NnhM1vpZ0IiPXg9Q8 Ij9WVj0bBVgufA1eY7DqaqqzN9+xipu/Sih/HynM8SbP5OdL+IizzwCU6H1/JnJi Bibxnc1VuXY= =Pw7H -END PGP SIGNATURE- --- End of forwarded message ---
Re: 3026 public symbol exports in LyX global name space (wa: Re: LaTeX file handling)
On 6 Sep 1999 06:13:13 +0900, [EMAIL PROTECTED] wrote: >"Arnd Hanses" <[EMAIL PROTECTED]> wrote: > >> Going up the stack 'till main() I'm now convinced that _heapset(9) >> produces on my box a self-induced crash (heap corruption) in emx libs. >> I'm unsure why this happens, it shouldn't, I think (or did I forget >> misunderstand it's function: Heap freespace setting to specified >> value?). Is this reproducible? > >I may be wrong, but once unused heaps are filled with non-zero >values it is not necessarily harmful to receive _HEAPBADNODE with >_heapchk(). [...] Notice _heap* >functions do not set errno. In fact don't receive anything, simply crashing, core complete garbage. Maybe, I should check libs of different patch levels, report behaviour to emx list. If I'm not too lazy... >Probably errno thingy is more important. Sure! A kingdom for a clue :) Tracing down looks like much work ... :( Regards, Arnd
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
> "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. 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? JMarc
lyx 0.10
Hi, I wish to know if lyx 0.10 and 0.12 are year 2000 compliant. Cany you answer it? Thanks, -- Oscar Guell Perez University of Catalonia Tel 93 401 73 27 [EMAIL PROTECTED] http://www.lsi.upc.es/~oskar
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: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "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. if fprintf works we can switch to that without problems (in 1.0.x) In 1.1.x we will not use C i/o. | 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? No, it should not be...but if there is a bug in the library.. Lgb
xforms 0.89
Hava anyone been able to compile and run LyX with xfroms 0.89? I get a (gdb) run Starting program: /home/larsbj/Development/lyx/src/lyx BadDrawable (invalid Pixmap or Window parameter) when trying. It seems that it crashes in the initialization of the xpm part of the lib. (I don't link with libXpm, I commented out the one line in mathed/math_symbols.c that needs it) I am not quite sure what is happening. Any input? Lgb
Re: xforms 0.89
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Hava anyone been able to compile and run LyX with xfroms 0.89? Lars> I get a (gdb) run Starting program: Lars> /home/larsbj/Development/lyx/src/lyx BadDrawable (invalid Pixmap Lars> or Window parameter) Lars> when trying. It seems that it crashes in the initialization of Lars> the xpm part of the lib. Do you build inside the development tree? I get that with 0.88.1 because I build outside the dev tree. In this case, when starting lyx as 'src/lyx', the code which finds the library path gets confused (some of-by-one error in string handling, I believe). It did not have time to fix it, but I think the X error is due to the fact that some pixmap is not found correctly, and is not related to 0.89. JMarc
Re: xforms 0.89
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Do you build inside the development tree? I get that with 0.88.1
| because I build outside the dev tree. In this case, when starting lyx
| as 'src/lyx', the code which finds the library path gets confused
| (some of-by-one error in string handling, I believe).
I build inside the developmen tree.
I can't see the off-by-one error.
from the trace:
#10 0x80dc110 in setPixmap (obj=0x81cf108, action=4, buttonwidth=30,
height=30)
at toolbar.C:173
173 fl_set_pixmapbutton_file(obj,
fullname.c_str());
(gdb) p fullname
$1 = {static npos = 4294967295, rep = 0x81cf348}
(gdb) p fullname.rep
$2 = (Srep *) 0x81cf348
(gdb) p *fullname.rep
$3 = {static xtra = , sz = 55, ref = 1, res = 59,
s = 0x81cf398 "/home/larsbj/Development/lyx/lib/images/buffer-open.xpm"}
and
[larsbj@cube larsbj]$ ls /home/larsbj/Development/lyx/lib/images/buffer-open.xpm
/home/larsbj/Development/lyx/lib/images/buffer-open.xpm
So I can't see any problems there.
Lgb
Re: xforms 0.89
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Do you build inside the development tree? I get that with 0.88.1 Lars> | because I build outside the dev tree. In this case, when Lars> starting lyx | as 'src/lyx', the code which finds the library Lars> path gets confused | (some of-by-one error in string handling, I Lars> believe). Lars> I build inside the developmen tree. I can't see the off-by-one Lars> error. Do you use the static or dynamic xforms library? One has libxpm built-in but with the other, it might happen that you have a dynamic libxpm with version !=3.4k (the one used by xforms) and that there is a binary incompatibility... I'm not sure that what I wrote makes sense, but... JMarc
Re: \title[foo]{bar} et al.
On Fri, 3 Sep 1999, Amir Karger wrote:
> Question for the latex gurus in the audience.
>
> One popular complaint about lyx 1.0 is that you can't get the equivalent of
> \section[short]{long section title}.
> [...]
Hi Amir,
I posted exactly the same trick some months ago to get short caption
entries in the listofwhatever. It is easily generalized to headings.
>From [EMAIL PROTECTED] Mon Sep 6 17:56:21 1999
Date: Thu, 15 Apr 1999 10:32:01 +0200 (MESZ)
From: Fred Hucht <[EMAIL PROTECTED]>
To: LyX Development Mailing List <[EMAIL PROTECTED]>
Subject: Re: clip figures script... and some more tricks
Hi,
one alternative is to use TeX to turn clipping on. I use
%--
\makeatletter
\newcommand{\Clip}[1]{%
\let\zztmp=\includegraphics%
\def\includegraphics{\Gin@cliptrue\Gin@i}%
#1%
\let\includegraphics=\zztmp%
}
\makeatother
%--
and then put a '\Clip{' before and a '}' after the tobeclipped
graphics. To clip all graphics use
%--
\makeatletter
\def\includegraphics{\Gin@cliptrue\Gin@i}
\makeatother
%--
in the preamble.
Other TeX stuff I use include the handy
%--
\newcommand{\C}[1]{{}} % Comment
%--
to comment out whole blocks of LyX text.
Also useful is the combo
%--
\makeatletter
\newcommand{\CapListEntry}[1]{\def\@CapListEntryFlag{1}\def\@CapListEntryText{#1}}
\def\@CapListEntryFlag{0}
\def\caption#1{\refstepcounter\@captype%
\ifodd\@CapListEntryFlag%
\@dblarg{\@caption\@captype}[\@CapListEntryText]{#1}%
\def\@CapListEntryFlag{0}%
\else%
\@dblarg{\@caption\@captype}{#1}%
\fi}
\makeatother
%--
to use the optional argument or caption, i.e. allow different text in
the list of figures/tables. CapListEntry can be made a LyX environment
by adding
# --
# Caption style definition
Style CapListEntry
MarginFirst_Dynamic
LatexType Command
LatexName CapListEntry
NeedProtect 1
LabelSep x
ParSkip 0
TopSep0
Align Block
AlignPossible Block, Left
LabelType Static
LabelString Entry:
Font
SizeSmall
EndFont
End
# --
to ~/.lyx/layouts/stdlayouts.inc.
Then, just put the CapListEntry environment before tha caption
environment and...
have fun,
Fred
Fred Hucht, Institute of Theoretical Physics, University of Duisburg, Germany
Email: [EMAIL PROTECTED] http://www.thp.Uni-Duisburg.DE/
"Der Koerper der algebraischen Zahlen ist kein algebraischer Zahlkoerper"
(E. Landau, Zahlentheorie (1927), Satz 718)
Re: Warning! POSIX does not buy you much...
Duncan Simpson <[EMAIL PROTECTED]> writes: Ok, this is known. But what has this _really_ to do with the Subject? | According to my man page strcasecmp is conforming to BSD 4.3 (and | all unicies | I have seen so far, inclduign SunOS). AFAIK GNU libc 2.1 is | conforming to ANSI | and POSIX but also includes common extensions, like mmap, lstat, setrlimit, | snprintf, select, fileno, *BSD sockets and whole bunch of other | stuff that is | endemic in un*x source code and supported everywhere with very few | exceptions. | I can use fdopen in POSIX programs. There are also some things that | only exist | in glibc, and linux libc 5, like strfry(3) and memfrob(3), which are | presumably included for hack value. | | The average punter, and Un*x programmer, is not aware of how little POSIX | gives him. As soon as you prevent a remote root exploit by using | snprintf you | have violated POSIX And you don't know if you prog will compile on a system not running gnu libs. |---and of course by doing any networking and using | select(2) you have violated POSIX anyway. All internationalisation is beyond | the POSIX standard too. Not quite true, check man setlocale: CONFORMING TO ANSI C, POSIX.1 | BTW word2x has a source file that gives you strcasecmp and | strncasecmp if you | do not have them. LyX can steal it by GPL magic, which might GPL LyX on a | technicality. I think LyX is already GPLed anyway :-) We do not want to use strcasecmp, and in LyX 1.1.x we are getting rid of it. (using more native C++ constructs instead.) And yes, LyX is GPL, and has always been. (excetp for the very beginning perhaps) Lgb
["Andrew S. Townley" <atownley@informix.com>] Re: new prerelease LyX-1.0.4pre6
I have forwarded your msg to the devel lyx. I am sure our DocBook person will answer your questions. Lgb --- Start of forwarded message --- Message-Id: <[EMAIL PROTECTED]> Date: Mon, 06 Sep 1999 18:10:16 + From: "Andrew S. Townley" <[EMAIL PROTECTED]> To: Lars Gullik =?iso-8859-1?Q?Bj=F8nnes?= <[EMAIL PROTECTED]> Subject: Re: new prerelease LyX-1.0.4pre6 References: <[EMAIL PROTECTED]> Hi. I have been using lyx for several months now (again, actually. I had used it a long time ago as well), but the main thing that I am using it for right now is to generate SGML for publication in both PS and HTML formats. I am very pleased to see how well the DocBook support is progressing, but I was wondering about a couple of things: 1) In the finished DocBook support, will we be able to use tables and images in lyx and have them appear appropriately in both the PS and HTML output? In playing with the DocBook support, I noticed that the tables were at least available, but when they were translated to HTML, they didn't have the appropriate HTML formatting. 2) Images were really strange: if I used formats that LyX understands, they aren't displayable by the browsers. Is there some sort of a plan to be able to support more image formats and have LyX deal with the appropriate conversions when the SGML is exported? My goal is to be able to use LyX for the creation of Functional Specifications as well as user documentation for some of our internally developed tools. Right now, I don't have a really good tool that will allow me to quickly create documents that are publishable in HTML but that also provide a really good version for printing. If you're not the correct person to ask, I'm sorry to bother you. With each new release of the DocBook-aware LyX, I'm just getting more hopeful... :) Thanks for your time, ast "Lars Gullik Bjønnes" wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Docbook support is not quite finished so we will most likely have at > least one more prerelease before 1.0.4 proper. > > Changes in this pre: > > - - better scroll-wheel support (found on certain mice) > - - custom-pagesize support is better. (really a bug) > - - short index label. > - - latex run algorithms log parsing changed. (test this please) > > Also a couple of bugs, fixed. > > As alway with prereleases be careful. Make a backup of your important > documents. > > Get the prerelease from: > > ftp://ftp.lyx.org/pub/lyx/stable/lyx-1.0.4pre6.tar.gz > ftp://ftp.devel.lyx.org/pub/lyx/lyx-1.0.4pre6.tar.gz > ftp://la1ad.uio.no/pub/lyx/lyx-1.0.4pre6.tar.gz > > Lgb > -BEGIN PGP SIGNATURE- > Version: PGPfreeware 5.0i for non-commercial use > Comment: Processed by Mailcrypt 3.5.2, an Emacs/PGP interface > Charset: noconv > > iQCVAwUBN8S2mXfblV6DEjKhAQG9XgP/Q63UHFXTIq5FymBhMJi1IYuQvICiOpFf > PTzaLHI2e2QkfNySMH/fJNZ47kVsujkTuy/ri1Ou/+dYNF6NnhM1vpZ0IiPXg9Q8 > Ij9WVj0bBVgufA1eY7DqaqqzN9+xipu/Sih/HynM8SbP5OdL+IizzwCU6H1/JnJi > Bibxnc1VuXY= > =Pw7H > -END PGP SIGNATURE- --- End of forwarded message ---
