Would anyone else find this useful?  I started writing it, and I'm past the
hardest part, and am left with just the tedious task of finding all the
keywords defined in POV, and implementing the symantic control of which
keywords are allowed in which objects.

For the most part what I need works, but can anyone give me a good reason to
go ahead and complete this 100%?

Andrew Wilcox

Post a reply to this message

In article <3dee6e6c$1@news.povray.org> , "Andrew Wilcox" 
<awi### [at] unpuzzledcom> wrote:

> For the most part what I need works

Macros?

    Thorsten

Post a reply to this message

Actually, just parsing expressions is what I consider the hardest part.
Right now, it lexes, tokenizes, and starts objectizing the stream.  It
doesn't actually evaluate directives yet, but this is really just symbol
table manipulation which for the most part isn't too hard.

> > For the most part what I need works
>
> Macros?
>
>     Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > For the most part what I need works
> 
> Macros?
> 

Functions? ;-)

For a POV-Ray 3.5 compatible parser you really would need to duplicate
half of POV-Ray to successfully parse a POV-Ray scene, even if you leave
out textures.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Maybe I should reclarify.  I don't think actually fully parsing the scene is
feasible anytime soon, especially with functions, but building a parse tree
is.  Which would allow for manipulation of the scene language itself.  This
could then be rewritten and let POV actually do the full parse to generate
the scene.  I can't think of a good reason for actually evaluating the
scene.

AW

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3DEE750B.3B747C9B@gmx.de...
>
>
> Thorsten Froehlich wrote:
> >
> > > For the most part what I need works
> >
> > Macros?
> >
>
> Functions? ;-)
>
> For a POV-Ray 3.5 compatible parser you really would need to duplicate
> half of POV-Ray to successfully parse a POV-Ray scene, even if you leave
> out textures.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 15 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Andrew Wilcox" <awi### [at] unpuzzledcom> wrote
> Would anyone else find this useful?

Most definitely, no -- if by "useful" you mean something that could be used
for any real-world applications and not just in a students' toy project,
thesis, and the likes.

What (I think) would be indeed highly useful are lex/flex and bison/yacc
conunterparts with licenses more open than GPL. In fact, a good FSM-based
parser is what POV-Ray is currently missing badly, IMHO.

Post a reply to this message

Could be very interesting for a remote-POV-Ray computing website. You have a
heavy box running POV-Ray on the webserver with https (ssl) and you can
render stuff from anywhere you are, just using a web-browser with Java
enabled or a java application with sockets. The rendered output comes back
to where you are or is being mailed to an e-mail address. Maybe some thing
like global settings {mailto bil### [at] microsoftcom} would be funny
enhancement for the remote povray thing ?  :-)

Post a reply to this message

in article 3dee76e1@news.povray.org, Andrew Wilcox at awi### [at] unpuzzledcom
wrote on 4/12/02 9:43 pm:

> Maybe I should reclarify.  I don't think actually fully parsing the scene is
> feasible anytime soon, especially with functions, but building a parse tree
> is.  Which would allow for manipulation of the scene language itself.  This
> could then be rewritten and let POV actually do the full parse to generate
> the scene.  I can't think of a good reason for actually evaluating the
> scene.
> 
> AW

Hi Andrew, are you writing the parser by hand? If yes, then you should have
a look at either JFlex and CUP (java equivalent to flex and bison), SableCC
(which generates the parse tree for you) or ANTLR (which allow you to define
tree walkers as well as parsers and scanners). SableCC you can download it
from www.sablecc.org. ANTLR you can download it from www.antlr.org, JFlex
you can download it from www.jflex.de and CUP you can download it from
http://www.cs.princeton.edu/~appel/modern/java/CUP/.

Try SableCC as it is very easy to use.

All the best

Fidel.

Post a reply to this message

Well, I've thought of a couple of potential uses.  My overall goal is trying
to build a render farm program, and there are some tricky points.  One of
the things I am trying to do is determine all the resource files needed by a
POV-Ray scene file.  Things like #include files, and image files for
mappings and such.  To some degree even resources where the name is
generated at parse time could be figured out, unless some super complicated
method is used (like using a function or something).  Also, if done right
you could add syntax which could be parsed and rewritten in standard POV
SDL.  For example adding a #for statement, that gets rewritten as a #while.
It wouldn't be something most people would want to do, but it might make my
life easier sometimes. :-)

AW

Post a reply to this message

In article <3e1b06b8$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> What (I think) would be indeed highly useful are lex/flex and bison/yacc
> conunterparts with licenses more open than GPL. In fact, a good FSM-based
> parser is what POV-Ray is currently missing badly, IMHO.

No, that isn't correct.  You should not make such bold claims without
profiling the code first!  And this issue has been discussed often in the
past.

    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