Many macros are being rejected by MegaPov 0.4
compiled for DOS (djgpp 2.03, gcc 2.95.2).
For example, on parsing

/*****************/
#macro f(m)
        m
#end

#local d=f(0);
/*****************/

MegaPov tells me  that it is finding a ';' instead of an expected
object or directive (this is with or without a
    "#version unofficial MegaPov 0.4"
It works fine with the WinMegaPov 0.4 so I am guessing the problem
has something to do some difference in compilers or OS.
Looking throught the parser code makes me dizzy and I am at a loss
trying to find a fix for this.
What could it be?

Post a reply to this message

In article <38963bc2@news.povray.org> , "david sharp" <dsh### [at] interportnet>
wrote:

> Many macros are being rejected by MegaPov 0.4
> compiled for DOS (djgpp 2.03, gcc 2.95.2).
> For example, on parsing
>
> /*****************/
> #macro f(m)
>         m
> #end
>
> #local d=f(0);
> /*****************/
>
> MegaPov tells me  that it is finding a ';' instead of an expected
> object or directive (this is with or without a
>     "#version unofficial MegaPov 0.4"
> It works fine with the WinMegaPov 0.4 so I am guessing the problem
> has something to do some difference in compilers or OS.
> Looking throught the parser code makes me dizzy and I am at a loss
> trying to find a fix for this.
> What could it be?

See "A trivial #version conundrum".  This problem is related to FPU
precision (causing 3.1 to end up as something like 3.099999 but be compared
to 3.100000001), search the whole source code for "3.1" and replace it with
"3.05", that will fix the problem.


      Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

But MegaPov is parsing the macro, just doing a bad job of it.
Like maybe the macro parsing is losing a character somewhere
or something.

Thorsten Froehlich <tho### [at] trfde> wrote in message
news:389640f0@news.povray.org...
> In article <38963bc2@news.povray.org> , "david sharp"
<dsh### [at] interportnet>
> wrote:
>
> > Many macros are being rejected by MegaPov 0.4
> > compiled for DOS (djgpp 2.03, gcc 2.95.2).
> > For example, on parsing
> >
> > /*****************/
> > #macro f(m)
> >         m
> > #end
> >
> > #local d=f(0);
> > /*****************/
> >
> > MegaPov tells me  that it is finding a ';' instead of an expected
> > object or directive (this is with or without a
> >     "#version unofficial MegaPov 0.4"
> > It works fine with the WinMegaPov 0.4 so I am guessing the problem
> > has something to do some difference in compilers or OS.
> > Looking throught the parser code makes me dizzy and I am at a loss
> > trying to find a fix for this.
> > What could it be?
>
> See "A trivial #version conundrum".  This problem is related to FPU
> precision (causing 3.1 to end up as something like 3.099999 but be
compared
> to 3.100000001), search the whole source code for "3.1" and replace it
with
> "3.05", that will fix the problem.

Post a reply to this message

I did try replacing "3.1"s with "3.05"s  but  there
was no change in my macro parsing trouble.

Post a reply to this message

In article <389658e4@news.povray.org> , "david sharp" <dsh### [at] interportnet>
wrote:

> I did try replacing "3.1"s with "3.05"s  but  there
> was no change in my macro parsing trouble.

Sorry, then I am out of ideas without looking at the source (for which I
have no time).


      Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Disabling FastMacroPatch lets the macros work, but
thats not quite satisfactory. I want the macros FAST, too!

For some reason there is a problem with the FastMacroPatch
as compiled by djgpp under ms-dos.

Post a reply to this message

I just tried it with MegaPov 0.4 compiled with gcc 2.95.1 in Solaris and
it worked fine.
  It has to be a djgpp-specific problem.

-- 
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

Nieminen Juha wrote:
 
>   I just tried it with MegaPov 0.4 compiled with gcc 2.95.1 in Solaris and
> it worked fine.
>   It has to be a djgpp-specific problem.

I'm unable to reproduce the problem with the Linux version (gcc 2.91.66,
yes, I need to upgrade).

-Mark Gordon

Post a reply to this message

david sharp <dsh### [at] interportnet> wrote...
>
> Disabling FastMacroPatch lets the macros work, but
> thats not quite satisfactory. I want the macros FAST, too!
>
> For some reason there is a problem with the FastMacroPatch
> as compiled by djgpp under ms-dos.
>

Try converting between DOS (cr+lf) and unix (lf only) text files - this will
probably have an affect on it.  Compilers, unfortunately, are not standard
in how they handle fseek() and ftell(), especially when dealing with DOS
files.  I've got code in there that's supposed to handle all situations, but
I guess I didn't anticipate whatever DJGPP is doing to the code.

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] Koppcom> wrote in message
news:3897435b@news.povray.org...

> > For some reason there is a problem with the FastMacroPatch
> > as compiled by djgpp under ms-dos.
> >
>
> Try converting between DOS (cr+lf) and unix (lf only) text files - this
will
> probably have an affect on it.  Compilers, unfortunately, are not standard
> in how they handle fseek() and ftell(), especially when dealing with DOS
> files.  I've got code in there that's supposed to handle all situations,
but
> I guess I didn't anticipate whatever DJGPP is doing to the code.

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?

Post a reply to this message

david sharp <dsh### [at] interportnet> 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

"Jon A. Cruz" <jon### [at] geocitiescom> writes:

> 
> 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. 

That's why I let EMACS do the indentation do for me. This results in
a correct indentation in the sense that it reflects the assignment of
lines to loops and if statements.

If you are used to this code styling (which is the case for me), you
won't forget the braces when you add a second line. If I'm urged
to make the braces, I would have added them like this:

{
  if(Ch=='\n') 
    { ungetc ('\r', (FILE *) File->Data); }

  ungetc (Ch, (FILE *) File->Data);
}

It is more compact and therefore clearer in my opinion.


> 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! 

Because of this, I add braces to my multi-line macros. (In C++ I don't
use multi-line macros at all.)

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

On 3 Feb 2000 03:14:41 -0500, Nieminen Juha wrote:
>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.

I think this belongs in the "For your information" thread, as it's a 
religious battle.  FWIW, the indenting style above is at least as accepted
as the one you're advocating, for the simple reason that it lets you fit
more code in a screenful without sacrificing much in the way of readability.

-- 
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

david sharp <dsh### [at] interportnet> wrote...
> Many macros are being rejected by MegaPov 0.4
> compiled for DOS (djgpp 2.03, gcc 2.95.2).

Opening POV and INC files in binary mode (as has been suggested) appears to
work, at least with the Windows compile.  I just changed the string
READ_TXTFILE_STRING to READ_BINFILE_STRING in two calls to fopen  (line 1112
in Initialize_Tokenizer and line 3651 in Open_Include).  Could people on
other OSs please test this potential fix (remove the #ifdef _GO32_ stuff in
unget first, though)?  Thanks.

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] Koppcom> wrote in message
news:38999aa7@news.povray.org...
> Opening POV and INC files in binary mode (as has been suggested) appears
to
> work, at least with the Windows compile.  I just changed the string
> READ_TXTFILE_STRING to READ_BINFILE_STRING in two calls to fopen  (line
1112
> in Initialize_Tokenizer and line 3651 in Open_Include).  Could people on
> other OSs please test this potential fix (remove the #ifdef _GO32_ stuff
in
> unget first, though)?  Thanks.

This works (so far) for MS-DOS, with the advantage that it can now read UNIX
or
MS-DOS style files.

Post a reply to this message

Nathan Kopp wrote:

> Could people on
> other OSs please test this potential fix (remove the #ifdef _GO32_ stuff in
> unget first, though)?  Thanks.

I had no problems in Linux after making the change (though I couldn't
find any reference to _GO32_ anywhere).

-Mark Gordon

Post a reply to this message

Thomas Willhalm wrote:

> That's why I let EMACS do the indentation do for me. This results in
> a correct indentation in the sense that it reflects the assignment of
> lines to loops and if statements.

Yes. But once a single maintenance person comes by months or years later
who doesn't...

[SNIP]

> Because of this, I add braces to my multi-line macros. (In C++ I don't
> use multi-line macros at all.)

Right. Wich I also do (when I do it). I also make sure to user parenthesis
around macro parameters in the macro itself also...

But some may not. Especially in large and/or longer-lived projects.

--
"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

Ron Parker wrote:

> On 3 Feb 2000 03:14:41 -0500, Nieminen Juha wrote:
> >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.
>
> I think this belongs in the "For your information" thread, as it's a
> religious battle.  FWIW, the indenting style above is at least as accepted
> as the one you're advocating, for the simple reason that it lets you fit
> more code in a screenful without sacrificing much in the way of readability.

Also, some argue that the lining up of closing braces with the opening brace
might be not as readable as lining it up with the construct that had the body.
i.e. the closing brace closes the 'if' not the '{'. So for many it is more
readable. Of course, if you also have the practice of always using braces, this
is more true.

But I don't care so much where they go, just that they are there somewhere.

--
"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 <jon### [at] geocitiescom> wrote:
:> I think this belongs in the "For your information" thread, as it's a
:> religious battle.  FWIW, the indenting style above is at least as accepted
:> as the one you're advocating, for the simple reason that it lets you fit
:> more code in a screenful without sacrificing much in the way of readability.

: Also, some argue that the lining up of closing braces with the opening brace
: might be not as readable as lining it up with the construct that had the body.
: i.e. the closing brace closes the 'if' not the '{'. So for many it is more
: readable. Of course, if you also have the practice of always using braces, this
: is more true.

  Of course both are lined. In this way:

  if(whatever)
  {
      command1();
      command2();
      command3();
      command4();
  }

  I seriously have trouble seeing where does the block begin and which command
does it belong to if the opening brace is at the end of the previous line.
I sometimes have to read code made that way and it takes a lot longer to
see and understand.
  I'm so accustomed to that format which I cited above that I almost
immediately see the beginning and ending of the block and the command which
it belongs to.
  Of course someone else may be accustomed to the other way. However, I have
serious difficulties interpreting that kind of code. This is specially true
when there are several nested and consecutive blocks with several lines of
code in each block.

-- 
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

I use this type:

if(whatever)
{
    command1();
    command2();
    command3();
    command4();
}

when writing C or C++, but I use this type:

object {MAIN_PARAMETERS
    OTHER_STUFF
}

when writing POV code.
Each one has it's own logical arguments, but I find the first one easier 
to read with loops and conditionals(probably because I am used to seeing 
C code that way). Since POV doesn't use curly brackets for those...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Mark Gordon <mtg### [at] mailbagcom> wrote...
> Nathan Kopp wrote:
>
> > Could people on
> > other OSs please test this potential fix (remove the #ifdef _GO32_ stuff
in
> > unget first, though)?  Thanks.
>
> I had no problems in Linux after making the change (though I couldn't
> find any reference to _GO32_ anywhere).

The _GO32_ stuff was David's first fix (post dated 2/2/2000), and was not
part of MegaPov 0.4.

-Nathan

Post a reply to this message