![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38963bc2@news.povray.org> , "david sharp" <dsh### [at] interport net>
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] povray org
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] trf de> wrote in message
news:389640f0@news.povray.org...
> In article <38963bc2@news.povray.org> , "david sharp"
<dsh### [at] interport net>
> 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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <389658e4@news.povray.org> , "david sharp" <dsh### [at] interport net>
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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
david sharp <dsh### [at] interport net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nathan Kopp <Nat### [at] Kopp com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |