"Wolf" <nomail@nomail> wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
>
> > Right. Perhaps its is a chance for us that the new grammar is intended to be
> > simple (which does not mean 'limited'). However, if it appears that
> > ready-made lexical scanner generators are not OK for our purpose, writing a
> > hand-made one will not be very difficult to specialists. I hope ....
>
> Well, if the new SDL has a grammar which is not representable by a
> general-purpose lexical scanner generator like ANTLR there should be a
> quite good reason to do so. Why would you want to write a complete scanner
> generator if you get one for free by using open source products?
>
> You have to implement the parsing rules anyway. If you implement them by
> hand you will probably end up producing spaghetti code containing lot of
> "IF" statements.
> By writing a grammar specification and using a scanner generator you get
> much cleaner entry points to parts of the grammar (high-level ones like
> textures as well as low-level ones like vectors).
>
>
> Maybe a hand-written scanner is faster than a generated one, but speed
> considerations should not be overweighted here as the parsing time is
> negligible  compared to the rendering time.
>
> - Wolf

If the new syntax does not break the limitations of lexers, we can use one
of them, of course!

If you express the syntax in BNF form as an LL(1) grammar, you can write
quite easily a syntax-directed parser by applying well known rules between
BNF and the language (control statements) you write the parser in. Without
obtaining spaghetti. Perhaps there are some specialists in programing
languages here who can tell more.

My opinion is that whatever parsing technique is used, performances are not
much of a concern: with the machines we have today it will be ALWAYS very
quick for any scene/module we will ever have to parse. The renderer, on the
other hand, must be highly optimized for massive (and vectorized, because
it's the nature of the problem) computations.

Bruno

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Cabasson wrote:
> My opinion is that whatever parsing technique is used, performances are not
> much of a concern: with the machines we have today it will be ALWAYS very
> quick for any scene/module we will ever have to parse.

Some people here will beg to differ with you. :-)

Then again, with the exception of, say, large meshes, strictly *parsing*
a scene probably will always be fairly fast; it's the execution of SDL
loops and macros that gets hairy. However, Povray seems to consider that
as part of the "parsing" process.

FWIW, I've worked on scenes that took 10-15 seconds just to "parse" (due
to loops that procedurally generated lots and lots of objects).

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you hear a name beginning
with the letter K and wonder if it's David Buck's middle name.
    -- Alex McLeod a.k.a. Giant Robot Messiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBYnMcCmTzQ++ZncRAg2KAJ9gwSuXSegTq3ruAlntHzWEPFVCaQCgoHJr
0WTezCJyu4IzcqzUb/nSE8s=
=nm/j
-----END PGP SIGNATURE-----

Post a reply to this message

Tom York wrote:
> I find parsing can easily be comparable to the render time for the scenes I
> render (use of meshes and medium-complexity macros). 

What the current POV calls "parsing" isn't what things like ANTLR do. 
"Parsing" (in the non-POV sense) means building a data structure 
isomorphic to the input source code. "Parsing" in the POV sense includes 
things like executing the while loops, while in the ANTLR sense it does 
not. So with a parser generator, you'd have three phases: parsing 
(fast), evaluating (putting together all the objects in the scene), then 
rendering (calculating pixel colors).

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

> FWIW, I've worked on scenes that took 10-15 seconds just to "parse" (due
> to loops that procedurally generated lots and lots of objects).

that's nothing, I, and I believe I'm not the only one, have worked on scenes 
that took a couple of minutes to parse.
Very irritating sometimes, because a mosaic-preview of the scene often only 
takes a couple of seconds.  So I'll have to wait ten times the tracing-time 
just to notice the camera is facing the wrong direction :)

My point: unless you change the meaning of "parsing" (which doesn't speed up 
anything, and therefor would be, imho, considered useless), parsing is NOT 
neceseraalery (I hate that word, never get it even close to right, probably 
cause I'm not even trying anymore) 'very quick', on the contrary.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:

> What the current POV calls "parsing" isn't what things like ANTLR do.
> "Parsing" (in the non-POV sense) means building a data structure
> isomorphic to the input source code. "Parsing" in the POV sense includes
> things like executing the while loops, while in the ANTLR sense it does
> not. So with a parser generator, you'd have three phases: parsing
> (fast), evaluating (putting together all the objects in the scene), then
> rendering (calculating pixel colors).

My point above was mainly concerned with how *OTHER* tools can *VALIDATE*
any given SDL code, not with how POV-ray will parse a SDL.
In my example I need a lexer for PovClipse telling me what's wrong with a
given SDL. I do not need to care about how POV-ray will internally
implement the step between the SDL token recognition and building the
internal data structure.
All I need to know is:
* is the SDL valid
* if not, where are the errors (missing braces, semicolons, misspellings...)

In order to archive this the best thing to have is a complete,
programmatically usable sytactical grammar description which you can easily
feed into tools like ANTLR.
And in my opinion the one providing such a grammar description should be the
one implementing it, thus POV-ray.

- Wolf

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:

> My point: unless you change the meaning of "parsing" (which doesn't speed up
> anything, and therefor would be, imho, considered useless), parsing is NOT
> neceseraalery (I hate that word, never get it even close to right, probably
> cause I'm not even trying anymore) 'very quick', on the contrary.

OK, let's clarify things a bit:

This thread is concerned with the part from reading the SDL file to
recognize the SDL tokens within it *ONLY*.
The steps involved between token recognition and building the internal data
structure was never meant to be part of this discussion.
Obviously the time needed for this step(s) depends heavily on the *content*
of the SDL (many loops creating objects...), while the time needed to
recognize the SDL tokens should only be depended on the *length* of the SDL
file.

- Wolf

Post a reply to this message

> Darren New <dne### [at] sanrrcom> wrote:
> 
>> What the current POV calls "parsing" isn't what things like ANTLR do.
>> "Parsing" (in the non-POV sense) means building a data structure
>> isomorphic to the input source code. "Parsing" in the POV sense includes
>> things like executing the while loops, while in the ANTLR sense it does
>> not. So with a parser generator, you'd have three phases: parsing
>> (fast), evaluating (putting together all the objects in the scene), then
>> rendering (calculating pixel colors).
> 
> My point above was mainly concerned with how *OTHER* tools can *VALIDATE*
> any given SDL code, not with how POV-ray will parse a SDL.
> In my example I need a lexer for PovClipse telling me what's wrong with a
> given SDL. I do not need to care about how POV-ray will internally
> implement the step between the SDL token recognition and building the
> internal data structure.
> All I need to know is:
> * is the SDL valid
> * if not, where are the errors (missing braces, semicolons, misspellings...)
> 
> In order to archive this the best thing to have is a complete,
> programmatically usable sytactical grammar description which you can easily
> feed into tools like ANTLR.
> And in my opinion the one providing such a grammar description should be the
> one implementing it, thus POV-ray.
> 
> - Wolf
> 
> 

That's impossible to do with the current SDL syntax. Abusing macros and 
loops you could make the syntax change from valid to invalid depending 
on what frame number you're rendering. And the only way to test that is 
interpreting the whole scene code with the current parameters, which 
could very well take hours on some scenes with built-in physics 
simulations :)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> That's impossible to do with the current SDL syntax.

True, that's why I was referring to the new 4.0 syntax. For the 3.6 syntax
it *is* impossible to write a grammar usable with ANTLR, see my statements
above.

> Abusing macros and
> loops you could make the syntax change from valid to invalid depending
> on what frame number you're rendering.

Why would there be such a thing like syntactically invalid frame code? If
it's invalid POV-ray can not render it.

> And the only way to test that is
> interpreting the whole scene code with the current parameters, which
> could very well take hours on some scenes with built-in physics
> simulations :)

An option deactivating the automatic syntax validation could solve this as
well as the invalid-frame thing above.


- Wolf

Post a reply to this message

>> Abusing macros and
>> loops you could make the syntax change from valid to invalid depending
>> on what frame number you're rendering.
> 
> Why would there be such a thing like syntactically invalid frame code? If
> it's invalid POV-ray can not render it.
> 

Exactly. And you want PovClipse to notice that before POV-Ray attempts 
(and fails) to render it, right?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> >> Abusing macros and
> >> loops you could make the syntax change from valid to invalid depending
> >> on what frame number you're rendering.
> >
> > Why would there be such a thing like syntactically invalid frame code? If
> > it's invalid POV-ray can not render it.
> >
>
> Exactly. And you want PovClipse to notice that before POV-Ray attempts
> (and fails) to render it, right?

Yes indeed, that's the intention.
Part of this this feature is already implemented: PovClipse nags about any
word which is not a known POV or MegaPOV keyword, the name of a declared
variable or macro.
The next step would be the **syntactical** errors, but for this I need a
grammar definition to be used with ANTLR or similar tool, and this is what
this thread is all about.

- Wolf

Post a reply to this message