Am 13.10.2017 um 09:17 schrieb dick balaska:
> 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.

The difference there is that those languages are compiled, i.e. the
parser scans each portion of the file just once (or maybe twice or
thrice at worst), whether it is a straight piece of code or a loop.

It is only later that the code is actually executed.

That doesn't work with POV-Ray's SDL. For any piece of software to
"understand" the code, it needs to /interpret/ it, i.e. actually run the
code.


>> 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.

For small pieces of code, a way around this in the newest versions of
POV-Ray is to move that code into a macro of at most 64 kiB in size.
Such macros will now be cached in memory.

Post a reply to this message