Ron Parker schrieb in Nachricht <36b8526e.0@news.povray.org>...
>On Wed, 3 Feb 1999 14:10:20 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>>I have read somewhere, for #while loops, at the #end, the parser must
>>re-read the source to find the #while, like old BASIC dialects did.
>
>Not true, fortunately.  It stores the offset within the file where the
>#while appears and jumps directly to it upon hitting the #end.


Fortunately, yes.

>>Perhaps there would be demand for a small program, which unravels #while
>>loops and macros and creates (huge) include files out of them, taking a
bit
>>out of the parsing POV-Ray does.
>
>Interesting idea, but I'm not sure you'll save much time, as that's
>practically the same as what POV already does.  By seeking backward
>in the file, it essentially duplicates the code as many times as
>needed.  The only thing you'd save is a few seeks (nearly instantaneous
>anyway except when it's a macro defined in another file), a few
>expression evaluations (these could potentially be slow, but usually
>aren't), and a few symbol lookups on your index variable (very fast.)


Still, the parser is an interpreter. Even if the allocation of objects takes
much time, the interpreter also uses time, which Spider's example with the
pre-computed trees proves. A pre-compiler (generating some kind of p-code,
optimized for the language, perhaps) would be a nice feature IMHO. A good
one could even look ahead and optimize (optimise) the allocations (yes I'm
dreaming again).

I myself am used to a very fast compiler (Delphi), so waiting for a parse is
really annoying (first time I made a longer parse, I thought the program was
hanging). You (MSVC) C++ guys are propably used to longer compile times <g>.

But I agree with the POV-team, that normally the render time is much more of
a problem, so they should propably optimize (optimise) that first.

>I do wonder, though, if POV could be coaxed to output a .pov file
>in canonical form as it parses a set of .pov and .inc files - with
>commas inserted where necessary and looping and conditionals and
>symbols and includes (all the #-stuff) and comments removed.  I
>think this goes a bit further than you were proposing.  It'd be
>less readable to humans, but it would be oh-so-easy for third-party
>parsers to read, and perhaps slightly faster for POV as well.  Some
>files, like the mandelbrot set made of spheres, would run much more
>quickly.

It would propably allow for a .pov to <add your favorite modeller here>
converter, if that's what you mean. You would have some kind of .dxf file in
.pov format <g> (afaik, .dxf are plain text files, and they can be huge).

But you'll propably have to write a rather extensive parser for this. Once
you've done that, the rest won't be hard to implement anymore.

--
Rudy Velthuis

Post a reply to this message