"Possible Parse Error: Operation Timed Out"

What are the possible causes for this Time Out problem? I get it quite
often, maybe in 40% of all render attempts.

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:
> "Possible Parse Error: Operation Timed Out"
>
> What are the possible causes for this Time Out problem? I get it quite
> often, maybe in 40% of all render attempts.

Sounds like the parser wants some information from the front-end (a likely
candidate would be figuring out the actual name for a file specified in the
scene) but the front-end doesn't react fast enough for the parser's liking. (The
two run in separate threads.)

Slow system and huge scene, maybe?

Post a reply to this message

Yes. Both is correct.

This situation gives me the following thought:
A new version of POV-Ray should have more tolerance to slower systems
(auto-configuration of expectation time between these two threads?), or
a configuration possibility to set expectation time by hand. Just a
suggestion.

But what can I do right now about this problem?

---------------------------

On 21.01.2016 07:41, clipka wrote:
> Slow system and huge scene, maybe?

Post a reply to this message

Am 22.01.2016 um 20:52 schrieb Sven Littkowski:
> Yes. Both is correct.
> 
> This situation gives me the following thought:
> A new version of POV-Ray should have more tolerance to slower systems
> (auto-configuration of expectation time between these two threads?), or
> a configuration possibility to set expectation time by hand. Just a
> suggestion.

Currently, a timeout of 10 seconds is used, which doesn't seem /that/
unreasonable.

> But what can I do right now about this problem?

Buy a faster computer? ;)

That, or make another change to your own personal build of POV-Ray:

At the end of source/base/build.h (but before the last "#endif"), insert:

    #define kDefaultTimeout 60

to increase the timeout from 10 seconds to 1 minute. Or insert any value
you deem fitting.

Post a reply to this message

10 seconds? Yes, that seems long enough. I would think the same. But
still, it is not enough - at least not in my situation. :-(

Post a reply to this message

Sven Littkowski <jam### [at] yahoocom> wrote:
> "Possible Parse Error: Operation Timed Out"
>
> What are the possible causes for this Time Out problem? I get it quite
> often, maybe in 40% of all render attempts.

I also met this in a very simple scene in which texture paths had mixed
backslashes and forward slashes (it can be invisible such as
"//dir1/dir2/file.png" which I believe will get converted to
"\dir1/dir2/file.png" on windows...)
The new handling of (forward/back/)slashes is more rigid than before, what did
we gain from it?

Thanks Stephen for the specular test scene ;-)

Post a reply to this message

On 6/11/2017 8:40 PM, Mr wrote:
> Sven Littkowski <jam### [at] yahoocom> wrote:
>> "Possible Parse Error: Operation Timed Out"
>>
>> What are the possible causes for this Time Out problem? I get it quite
>> often, maybe in 40% of all render attempts.
>
> I also met this in a very simple scene in which texture paths had mixed
> backslashes and forward slashes (it can be invisible such as
> "//dir1/dir2/file.png" which I believe will get converted to
> "\dir1/dir2/file.png" on windows...)
> The new handling of (forward/back/)slashes is more rigid than before, what did
> we gain from it?
>
> Thanks Stephen for the specular test scene ;-)
>
>

Who said that and when? ;)

No problem.

-- 

Regards
     Stephen

Post a reply to this message

Am 11.06.2017 um 21:40 schrieb Mr:
> Sven Littkowski <jam### [at] yahoocom> wrote:
>> "Possible Parse Error: Operation Timed Out"
>>
>> What are the possible causes for this Time Out problem? I get it quite
>> often, maybe in 40% of all render attempts.
> 
> I also met this in a very simple scene in which texture paths had mixed
> backslashes and forward slashes (it can be invisible such as
> "//dir1/dir2/file.png" which I believe will get converted to
> "\dir1/dir2/file.png" on windows...)
> The new handling of (forward/back/)slashes is more rigid than before, what did
> we gain from it?

What we gained is a more consistent treatment of backslashes in strings.

Previously,

    #include "subdir\test.inc"

did something different than

    #declare FooBar = "subdir\test.inc";
    #include FooBar

with the former effectively resolving to `#include "subdir/test.inc"`,
and the latter effectively resolving to `#include "subdir<TAB>est.inc"`,
where <TAB> would be the tab character (ASCII character hex 09).

Essentially, the former behaviour applied to any string literal
appearing where a filename was expected, while the latter applied to
string literals in any other context.

This was never well documented for the Windows version, and entirely
undocumented for the Unix version, where this behaviour made no sense at
all.

Now both constructs effectively resolve to `#include
"subdir<TAB>est.inc"` -- which is probably not what you want in that
particular context, but it's fully consistent and matches the documentation.

It also simplifies the parser a little bit.


Since forward slashes work as file separators on all platforms, it is
strongly recommended to use those instead of backward slashes.


BTW, "//dir1/dir2/file.png" is _not_ converted to "\dir1/dir2/file.png"
on windows. It's the backward slashes that are converted (two backward
slashes, i.e. "\\", being interpreted as a literal single backward
slash, i.e. "\"), so "\\dir1/dir2/file.png" _would_ be converted to
"\dir1/dir2/file.png"

In POV-Ray for Windows, both forward and backward slashes are ultimately
interpreted as path separators (if the string is used in a filename
context). In POV-Ray for Unix, only forward slashes are interpreted that
way.

Post a reply to this message

Am 2017-06-11 16:44, also sprach clipka:

> BTW, "//dir1/dir2/file.png" is _not_ converted to "\dir1/dir2/file.png"
> on windows. It's the backward slashes that are converted (two backward
> slashes, i.e. "\\", being interpreted as a literal single backward
> slash, i.e. "\"), so "\\dir1/dir2/file.png" _would_ be converted to
> "\dir1/dir2/file.png"

It is timing out trying to find dir2/file.png on machine dir1.
//dir1 is a machine name (UNC path?)

-- 
dik

Post a reply to this message

Am 11.06.2017 um 23:49 schrieb dick balaska:
> Am 2017-06-11 16:44, also sprach clipka:
> 
>> BTW, "//dir1/dir2/file.png" is _not_ converted to "\dir1/dir2/file.png"
>> on windows. It's the backward slashes that are converted (two backward
>> slashes, i.e. "\\", being interpreted as a literal single backward
>> slash, i.e. "\"), so "\\dir1/dir2/file.png" _would_ be converted to
>> "\dir1/dir2/file.png"
> 
> It is timing out trying to find dir2/file.png on machine dir1.
> //dir1 is a machine name (UNC path?)

Sounds plausible.

File names `//Foo/Bar` or `\\Foo/Bar` (string literal "\\\\Foo/Bar")
would indeed be interpreted as "Bar" on machine "Foo".

And I wouldn't be surprised if the operating system gave you quite a
long timeout when attempting to access a file over the network, possibly
even longer than the default 10s POV-Ray is willing to wait.

Post a reply to this message