 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/05/2018 15:54, clipka wrote:
> Am 23.05.2018 um 10:22 schrieb Stephen:
>> On 22/05/2018 01:28, clipka wrote:
>>> - Backward compatibility with scenes that use single backslashes in
>>> literal filenames has been sacrificed, and will most likely not be
>>> restored.
>>
>> This is going to cause me problems using SDL generated by modellers.
>
> I'm zeroing in on the conclusion that this is a problem that's not
> easily solved in the new parser architecture, especially with respect to
> the future plans.
>
>
> The aim is to scan/tokenize a file only once, cache the result, and from
> then on only operate on the resulting token stream. Maybe even have a
> separate scanner/tokenizer thread go ahead with its job while the parser
> thread is still busy with earlier portions of the scene.
>
> This means that whatever looks identical, must be scanned/tokenized
> identically. Most notably, backslashes in string literals must be
> treated consistently: "foo\nbar" must always be translated as the
> character sequence `foo` followed by a newline followed by the character
> sequence `bar`, no matter whether the parser - based on neighboring
> tokens - expects a filename or a generic string at that particular location.
>
> -OR- the scanner/tokenizer would always have to translate such a string
> literal as the character sequence `foo\nbar`. But then the job of
> resolving the escape sequence would fall to the parser proper, and would
> have to be done over and over again each time the parser encounters the
> string literal. Since strings are comparatively heavyweight to process,
> that would be bad news in terms of performance.
>
>
> A similar problem exists with respect to character encoding: Without
> understanding of `global_settings { charset utf8 }`, the
> scanner/tokenizer cannot decide whether a non-ASCII byte sequence in a
> string literal should be interpreted according to UTF-8 or according to
> Windows-1252, Latin-1 or whatever.
>
Don't give me your problems. I have enough of my own. :)
A solution would be to get started on the replacement for Moray. The one
that Lutz Kretzschmar gave the licence, to the Pov group, in Feb 2007.
http://www.stmuc.com/moray/menews.html
[Don't say that I am not patient.]
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 23.05.2018 um 10:22 schrieb Stephen:
> > On 22/05/2018 01:28, clipka wrote:
> >> - Backward compatibility with scenes that use single backslashes in
> >> literal filenames has been sacrificed, and will most likely not be
> >> restored.
> >
> > This is going to cause me problems using SDL generated by modellers.
>
> I'm zeroing in on the conclusion that this is a problem that's not
> easily solved in the new parser architecture, especially with respect to
> the future plans.
Is it possible to write a simple read/write SDL file to open and process another
malformed SDL file and write it with the correct forms?
Not ideal but it (perhaps naively) seems like it would be a simple workaround.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.05.2018 um 18:07 schrieb Bald Eagle:
> Is it possible to write a simple read/write SDL file to open and process another
> malformed SDL file and write it with the correct forms?
It is -- for generous definitions of "possible" ;)
POV-Ray isn't particularly good at doing string operations.
> Not ideal but it (perhaps naively) seems like it would be a simple workaround.
I've now decided to go for a different approach: Translating each string
literal into two values, one to be used in generic contexts (with escape
sequences resolved), and another to be used in contexts where filenames
are expected (with escape sequences ignored). This leaves it up to the
parser proper to decide whether it wants one or the other.
One remaining issue would be the treatment of `\"`: If we wanted to
ignore all escape sequences, this should be interpreted as a backslash
followed by the end of the string, but in all other contexts it should
be interpreted as a literal double quote character; so even deciding
where the string ends would be a context-sensitive thing.
Fortunately, this is more of an academic issue, as trailing backslashes
aren't valid in file names anyway. (Directories, yes, but then they
would have to be combined with filenames via `concat` to form a valid
file name, and there the context would again be considered generic.)
Also, POV-Ray v3.7.0 already treats `\"` as escaped double quote even in
filenames (despite the character not even being valid there), and
according to the v3.0 docs this has always been the case.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 24.05.2018 um 10:04 schrieb Kenneth:
> > From this, it makes me wonder if the bulk of the parse-time-speedup is in
> > mesh2 meshes and/or trace...
>
> There is no speedup to be expected in the trace() function, nor is there
> any speedup to be expected in mesh2 /per se/.
>
> Just as a hunch, does your loop invoke any macros?
>
> If so, it's fundamentally different from Stephen's loop: The latest
> v3.8.0-x.tokenizer version can execute his loop from memory without
> performing any file access during the loop, but only because it does not
> invoke any macros.
>
> Each return from macro currently causes the file buffer to be re-loaded.
> To make matters worse, this re-loads only the portion /after/ the
> location the macro returns to, so when the end of the loop is reached,
> the next iteration requires another buffer re-load to get back to the
> start of the loop.
Yes, that is indeed the case with my own scene: macro calls within #while loops
(hundreds to thousands of such calls.) AND, in the current state of that
2400-code-line scene, there are more comments than actual code! I never cleaned
it up :-O
Maybe my SP (sloppy programming) is another factor that is 'swamping' any
improvements in the parse time. Mea culpa.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.05.2018 um 23:05 schrieb Kenneth:
> Yes, that is indeed the case with my own scene: macro calls within #while loops
> (hundreds to thousands of such calls.) AND, in the current state of that
> 2400-code-line scene, there are more comments than actual code! I never cleaned
> it up :-O
Comments are not an issue: They probably don't receive much of a
performance improvement, but they don't prevent other portions of the
loop from getting the best possible performance.
> Maybe my SP (sloppy programming) is another factor that is 'swamping' any
> improvements in the parse time. Mea culpa.
There is no mechanism to penalize sloppy programming.
Macros in a loop /are/ currently a major factor; once I get that sorted
out, your code should get about as much performance improvement as
anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/05/2018 14:37, clipka wrote:
> TL;DU: There are plausible explanations why current versions of POV-Ray
> may be utilizing your CPU more heavily (or at least differently) than
> v3.7.0 did.
As long as you can see a reason. I am happy.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> ... the new parser architecture, especially with respect to
> the future plans.
future plans sounds good. will it lead to a "lint" type command-line utility
for povray? ideally made and installed as part of the regular build. what do
you think?
(I didn't think it necessary to point out all the benefits of a lint :-))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.06.2018 um 16:28 schrieb jr:
> clipka <ano### [at] anonymousorg> wrote:
>> ... the new parser architecture, especially with respect to
>> the future plans.
>
> future plans sounds good. will it lead to a "lint" type command-line utility
> for povray? ideally made and installed as part of the regular build. what do
> you think?
> (I didn't think it necessary to point out all the benefits of a lint :-))
I doubt it. Some lint-ish checks might be performed by the parser before
actually running the scene code (I'm primarily thinking balanced and
well-nested "starting/ending" constructs, such as parentheses, curly
braces and square brackets vs. block directives such as macros,
conditionals and loops), but writing an external tool would mean
duplicating some effort, and that's not going to fly with our current
manpower.
A command-line option to tell the parser to only do initial checks and
not actually run the scene code, that would be a viable possibility.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> > ... will it lead to a "lint" type command-line utility ...
> A command-line option to tell the parser to only do initial checks and
> not actually run the scene code, that would be a viable possibility.
from my (user) perspective that would be exactly like having a basic lint,
so yes please, will you consider adding such an option?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/10/2018 10:13 PM, clipka wrote:
> A command-line option to tell the parser to only do initial checks and
> not actually run the scene code, that would be a viable possibility.
[like]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
