 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
david sharp <dsh### [at] interport net> wrote...
>
> Thanks much. Converting scene file cr-lf's to lf's 'fixes' the
> FastMacroPatch.
> (that is, lets the troublesome macros run).
>
> What is it that the FastMacroPatch does that other fseek/ftell dependent
> stuff in POV doesn't?
Not much different. Part of it is to use ftell twice to determine the
length of the macro. But the problem is that fread() reads a single byte
for CR+LF (converts two to '\n'), but ftell()-ftell() will give two bytes
for CR+LF. Unfortunately, this does not always happen and is not at all
consistent across operating systems or even compilers on the same OS.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] Koppcom> wrote in message
news:389789e9@news.povray.org...
>
> david sharp <dsh### [at] interportnet> wrote...
> >
> > What is it that the FastMacroPatch does that other fseek/ftell dependent
> > stuff in POV doesn't?
>
> Not much different. Part of it is to use ftell twice to determine the
> length of the macro. But the problem is that fread() reads a single byte
> for CR+LF (converts two to '\n'), but ftell()-ftell() will give two bytes
> for CR+LF. Unfortunately, this does not always happen and is not at all
> consistent across operating systems or even compilers on the same OS.
I just posted a message (since cancelled), about a fix. But it didn't
really (only coincidentally worked), so if anyone read it, forget it,
please.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 1 Feb 2000 20:33:49 -0500, Nathan Kopp wrote:
>Not much different. Part of it is to use ftell twice to determine the
>length of the macro. But the problem is that fread() reads a single byte
>for CR+LF (converts two to '\n'), but ftell()-ftell() will give two bytes
>for CR+LF. Unfortunately, this does not always happen and is not at all
>consistent across operating systems or even compilers on the same OS.
With all the problems CR/LF/CRLF cause us, why don't we just open the
scene files in binary mode?
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In tokenize.c, if I replace Fopen_Ungetc() with the following code,
MegaPov works on MS-DOS style scene files.
This is an inelegant way to go about it, but arf.
/***********************/
#ifdef __GO32__
static void Fopen_Ungetc (DATA_FILE *File, int Ch)
{
if(Ch=='\n')
ungetc ('\r', (FILE *) File->Data);
ungetc (Ch, (FILE *) File->Data);
}
#else
static void Fopen_Ungetc (DATA_FILE *File, int Ch)
{
ungetc (Ch, (FILE *) File->Data);
}
#endif
/***********************/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> On Tue, 1 Feb 2000 20:33:49 -0500, Nathan Kopp wrote:
> >Not much different. Part of it is to use ftell twice to determine the
> >length of the macro. But the problem is that fread() reads a single byte
> >for CR+LF (converts two to '\n'), but ftell()-ftell() will give two bytes
> >for CR+LF. Unfortunately, this does not always happen and is not at all
> >consistent across operating systems or even compilers on the same OS.
>
> With all the problems CR/LF/CRLF cause us, why don't we just open the
> scene files in binary mode?
Probably because if you open a file as binary, you'd have to manage the
conversion of CRLF to LF yourself, whereas opening in text mode handles some
of it for you. Especially for DOS/Windows programmers, opening in text mode
to get CRLF converted to LF is quite handy. Hmmm... I wonder if on the Mac it
converts the simple CR to LF?
Anyway, I think that's why. But I think that the why-not would probably
outweigh the why. Of course, my personal preference would be to read and
normalize EOL's and also to Unicode (UTF-8 or UTF-16) and make sure the
reading routines were written to handle this. Perhaps step one would be to
get away from direct dependence on ftell and isolate that in a buffer layer
that opens files in binary mode and handles EOL conversions. Step two could
be to then make this layer return Unicode and to handle that properly.
Once that was done, the program could handle all sorts of languages without
having to actually process in those charsets. Also, that could make things
work for people who don't have that specific language as their OS. That is, a
Japanese user could send me a Japanese POV-Ray source file and even though I
would be unable to read it, I could render it and get the exact same results
as the Japanese user did.
But... opening files in binary mode and handling the CRLF issues (even the
messed up CRCRLF that you get on Windows) probably would be best.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
david sharp wrote:
> In tokenize.c, if I replace Fopen_Ungetc() with the following code,
> MegaPov works on MS-DOS style scene files.
> This is an inelegant way to go about it, but arf.
>
> /***********************/
> #ifdef __GO32__
> static void Fopen_Ungetc (DATA_FILE *File, int Ch)
> {
> if(Ch=='\n')
> ungetc ('\r', (FILE *) File->Data);
> ungetc (Ch, (FILE *) File->Data);
> }
> #else
> static void Fopen_Ungetc (DATA_FILE *File, int Ch)
> {
> ungetc (Ch, (FILE *) File->Data);
> }
> #endif
> /***********************/
Could I bug you to try to always use braces, even for single line
bodies?
{
if(Ch=='\n') {
ungetc ('\r', (FILE *) File->Data);
}
ungetc (Ch, (FILE *) File->Data);
}
As opposed to some things that are just a matter of style ( e.g. where
you decide to place them), always using braces even for single line
bodies is a good idea that helps prevent problems. Sometimes it's
possible to write logic incorrectly and miss it due to misleading
indention, but braces would catch that. Also, there are times when what
you thought was a simple function might actually change to be a
multi-line macro... and if so, BOOM! And many more details, but I'll
hold those for later discussion, if needed.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz wrote:
> david sharp wrote:
>
> > In tokenize.c, if I replace Fopen_Ungetc() with the following code,
[ ... ]
> Could I bug you to try to always use braces, even for single line
> bodies?
It depends on what you mean by 'bug'. If you mean ominous threatening
calls in the middle of the night and renting the apartment upstairs and
installing loudspeakers pointed into the floor, please don't.
Your complaint is one I agree with when dealing with other people's
code, but often leave off braces myself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 02 Feb 2000 09:14:31 -0800, Jon A. Cruz wrote:
>Ron Parker wrote:
>> With all the problems CR/LF/CRLF cause us, why don't we just open the
>> scene files in binary mode?
>
>Probably because if you open a file as binary, you'd have to manage the
>conversion of CRLF to LF yourself, whereas opening in text mode handles some
>of it for you. Especially for DOS/Windows programmers, opening in text mode
>to get CRLF converted to LF is quite handy. Hmmm... I wonder if on the Mac it
>converts the simple CR to LF?
Other than //-comments, I can't think of any POV feature that distinguishes
between newlines and other whitespace, and there are none that care about
multiple newlines (unlike C, where a multiline #define gets messed up by
such things.) That being the case, CR and LF could each be treated as EOL
characters, and the weird DOS practice of putting both of them on each
line would just be handled like a double-spaced file. (CRCRLF would be
triple-spaced.)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: With all the problems CR/LF/CRLF cause us, why don't we just open the
: scene files in binary mode?
How does povray read the file? If it reads it one character at a time, then
I think this would be a good solution.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocitiescom> wrote:
: Could I bug you to try to always use braces, even for single line
: bodies?
: if(Ch=='\n') {
: ungetc ('\r', (FILE *) File->Data);
: }
Good idea, as long as you don't put the braces that way.
The opening brace of a block should be at the beginning of the block, not
at the end of the previous line.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
