On 10/11/2017 09:58 AM, clipka wrote:
> 
> Running the parser whenever the user has made a change and is now idle,
> is problematic for multiple reasons:
> 
> - The user could resume editing at any moment; in that case, parsing
> would have to be aborted. (Likewise, the user may be editing other files
> the scene needs, and the parser won't be able to detect that until it
> runs into the corresponding `#include` statement.)
> 
> - The current architecture doesn't allow parsing of unsaved files; so
> triggering the parser would only be possible once the user saves their
> file. More often than not, I guess, this will be when the user pushes
> the render button anyway.
> 

The povclipse2 parser re-parses in-memory/mid-edit, starting at the 
point of editing. (A gift from eclipse that all its language parsers 
share). It's not perfect, like I start with the whole symbol table, 
where, correctly, I should start with the symbol table at the point of 
editing.
This gives me quick feedback of typos for undefined foo and bad bracing. 
Then when user saves the files, I flush the symbol table and start over 
at the beginning.
If the user continues editing during parsing, it just aborts parsing and 
starts again at the "farthest north" unparsed point.

Elsewhere clipka mentioned the organic evolution of SDL as problematic.
It is indeed a unique language.  A 'C' style object definition language 
with a 'BASIC/BASH' style control language bolted on to it. And then the 
next generation bolted the pseudo-preprocessor/function #macro hybrid on 
top of that.
(I understand how it came to be, and I think all the Right Choices were 
made, but man, those semicolons kill me. ;) )

> Also, parsing involves a lot of I/O,
> which degrades overall performance and responsiveness of the system, and
> can't be offset by multicore architectures.

I haven't been in the povray parser much, but my understanding was there 
were copious amounts of fget/ftell/fseek, which slows things down.


-- 
dik

Post a reply to this message