clipka <ano### [at] anonymousorg> wrote:
> I agree; but we have to make concessions between what would be nice to
> have, and what we can bolt on to the existing parser architecture. Since
> I have no immediate idea how to tackle this one, and there are usually
> ways to work around the issue, I don't think it should have high priority.

I agree completely; the stuff I mentioned was just piddly little things
that are of quite low priority. The sorts of things that should go on the
backlog and may never be seen again frankly. ;-)

> 
>> I also noticed that I cannot do the following:
>> Short-circuit conditional ops (shocked me)
> 
> Short-circuit conditional ops (I presume you mean the `?:` ternary
> operator) are nice-to-have sugar, but probably difficult to implement,
> with the parser being as convoluted as it is; moreover, `#if ... #else
> ... #end` already provide a workaround if sort-circuit operation is
> really necessary.

I meant && and ||; apologies for being unclear.


> What bothers me much more is that we don't have a short-circuit `select`
> statement, at least in user-defined functions, as that is an actual
> factor in render performance of certain isosurfaces. But I prefer not to
> touch the current VM, and instead wait for it to be replaced with a new one.

Sort of like C# yield return? 

>> Unary modification and assignment (+= and so forth)
> 
> Purely syntactic sugar. Should be reasonably easy to implement, but
> isn't high on my personal agenda.

I agree, i was kist surprised by its absence. :)

> 
> My goal is to introduce a clean conceptual separation between the render
> engine and the parser, so that the parser (typically along with the
> front-end) could be replaced by something else entirely. Which means
> that there's still a lot of stuff to be moved from the parser to the
> render engine (most notably object initialization and certain
> post-parse/pre-render processing steps).
> 
> Bolting another layer on top of the parser? No, thanks.

I wasn't aware of that the engine and parser were so tightly coupled, but
had an inkling that might have been the case based on some of the items you
mentioned that needed to be done. I am starting to get the picture of why
the refactoring is so high priority.

>
> POV-Ray for Windows does provide a GUI plug-in API, which to my
> knowledge is how Moray interfaces to POV-Ray. I have never had a closer
> look at the interface though -- my guess is that it is not much more
> than a way for the plug-in to initiate a render of a POV or INI file.
> 
> 

I wonder what they were doing to get the render to occur in their own
hosted form window? That is the crux of it.

I am afraid that I will discover that they scanned the memory, located the
pov process and hooked into the live output of the renderer directly, then
just copied the memory contents and shoved it into a picture box. *shivers*

Ian

Post a reply to this message