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
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
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
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
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | --Multipart_Thu_Sep__2_11:54:48_1999-1 | Content-Type: text/plain; charset=US-ASCII | | | Has anyone (Asger?) seen this? I really do not know what are the | whereabouts of fwrite vs fprintf, but we should really look at it... fwrite is essentially fprintf without buffering. So it should be no problem switching to fprintf. (actually fprintf are preferrable because of the buffering) BUT it is strange, both fwrite and fprintf are conforming to ANSI C. Could it be that we are missing a file.close or a file.flush ? Lgb
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | --Multipart_Thu_Sep__2_11:54:48_1999-1 | Content-Type: text/plain; charset=US-ASCII | | | Has anyone (Asger?) seen this? I really do not know what are the | whereabouts of fwrite vs fprintf, but we should really look at it... fwrite is essentially fprintf without buffering. So it should be no problem switching to fprintf. (actually fprintf are preferrable because of the buffering) BUT it is strange, both fwrite and fprintf are conforming to ANSI C. Could it be that we are missing a file.close or a file.flush ? Lgb
[dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Has anyone (Asger?) seen this? I really do not know what are the whereabouts of fwrite vs fprintf, but we should really look at it... JMarc Hi, I've found a work around for the problem described below. In file buffer.C, section Buffer:makeLaTeXFile, "fwrite" is used to write out the TeX file. On our system (see below) this silently fails, producing no output. As a work around, I replaced the "fwrite" with "printf". That seems to work fine. Here are differences between the modified and original buffer.C from lyx-1.0.4pre4. 1853,1854c1853 // fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); fprintf(file,"%s",LFile.c_str()); // 26-Aug-99 DFN kludge --- fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); 1921,1923c1920,1921 //fwrite(preamble.c_str(), sizeof(char), // preamble.length(), file); fprintf(file,"%s",preamble.c_str()); // 26-Aug-99 DFN kludge --- fwrite(preamble.c_str(), sizeof(char), preamble.length(), file); 1993,1995c1991,1992 // fwrite(LFile.c_str(), sizeof(char), // LFile.length(), file); fprintf(file,"%s",LFile.c_str()); // 26-Aug-99 DFN kludge --- fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); 2020,2021c2017 // fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); fprintf(file,"%s",LFile.c_str()); // 26-Aug-99 DFN kludge --- fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); On Mon, 23 Aug 1999, David F. Nitz wrote: Hi, Thanks to those who responded to with suggestions regarding my problem getting Lyx to work on Solaris 2.6.1. Unfortunately, none of the suggestions hit the mark. Let me re-describe what appears to be the crux of the problem perhaps a bit more clearly. Operating System: Solaris 2.6 Compiler: gcc 2.7.2 (Ugh) Lyx versions tried: 1.01 pre-built binary 1.03 built from source 1.04pre built from source Problem: Can't export LaTex file. A ".tex" file is created, but size is always 0 bytes. No error or warning messages are generated. Any suggestions? Thanks. --- David F. Nitz ([EMAIL PROTECTED]) Physics Department, Michigan Tech Tel: (906)487-2274 Fax: (906) 487-2933 --- David F. Nitz ([EMAIL PROTECTED]) Physics Department, Michigan Tech Tel: (906)487-2274 Fax: (906) 487-2933
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
On Thu, 2 Sep 1999, Jean-Marc Lasgouttes wrote: Has anyone (Asger?) seen this? I really do not know what are the whereabouts of fwrite vs fprintf, but we should really look at it... I have LyX running on a Solaris-2.5.1 box without these problems; compiled with gcc-2.7.2.3. So I'm at a loss as to why this failed on Solaris 2.6.1 Allan. (ARRae)
[dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
Has anyone (Asger?) seen this? I really do not know what are the whereabouts of fwrite vs fprintf, but we should really look at it... JMarc Hi, I've found a work around for the problem described below. In file buffer.C, section Buffer:makeLaTeXFile, "fwrite" is used to write out the TeX file. On our system (see below) this silently fails, producing no output. As a work around, I replaced the "fwrite" with "printf". That seems to work fine. Here are differences between the modified and original buffer.C from lyx-1.0.4pre4. 1853,1854c1853 < // fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); < fprintf(file,"%s",LFile.c_str()); // 26-Aug-99 DFN kludge --- > fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); 1921,1923c1920,1921 < //fwrite(preamble.c_str(), sizeof(char), < // preamble.length(), file); < fprintf(file,"%s",preamble.c_str()); // 26-Aug-99 DFN kludge --- > fwrite(preamble.c_str(), sizeof(char), > preamble.length(), file); 1993,1995c1991,1992 < // fwrite(LFile.c_str(), sizeof(char), < // LFile.length(), file); < fprintf(file,"%s",LFile.c_str()); // 26-Aug-99 DFN kludge --- > fwrite(LFile.c_str(), sizeof(char), > LFile.length(), file); 2020,2021c2017 < // fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); < fprintf(file,"%s",LFile.c_str()); // 26-Aug-99 DFN kludge --- > fwrite(LFile.c_str(), sizeof(char), LFile.length(), file); On Mon, 23 Aug 1999, David F. Nitz wrote: > Hi, > > Thanks to those who responded to with suggestions regarding my > problem getting Lyx to work on Solaris 2.6.1. Unfortunately, > none of the suggestions hit the mark. Let me re-describe > what appears to be the crux of the problem perhaps a bit > more clearly. > > Operating System: Solaris 2.6 > Compiler: gcc 2.7.2 (Ugh) > > Lyx versions tried: 1.01 pre-built binary >1.03 built from source >1.04pre built from source > > Problem: > > Can't export LaTex file. A ".tex" file is created, but size is always 0 > bytes. No error or warning messages are generated. > > Any suggestions? Thanks. > > --- > David F. Nitz ([EMAIL PROTECTED]) > Physics Department, Michigan Tech > Tel: (906)487-2274 Fax: (906) 487-2933 > --- David F. Nitz ([EMAIL PROTECTED]) Physics Department, Michigan Tech Tel: (906)487-2274 Fax: (906) 487-2933
Re: [dfnitz@mtu.edu: Re: Still stuck on Solaris -- Resolved]
On Thu, 2 Sep 1999, Jean-Marc Lasgouttes wrote: > > Has anyone (Asger?) seen this? I really do not know what are the > whereabouts of fwrite vs fprintf, but we should really look at it... I have LyX running on a Solaris-2.5.1 box without these problems; compiled with gcc-2.7.2.3. So I'm at a loss as to why this failed on Solaris 2.6.1 Allan. (ARRae)
