On 7/10/20 11:12 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> ...
>> I'll play some more in the week, then post a list of .. issues.
> 
> turns out that, so far, there are only two things on that list.  :-)
> 
> one is that 'povr' displays "povray: I/O restrictions are disabled".  confused.
> the 'povray.conf' file contains (edited):
> 
...
> 
> the second problem is a "third party" scene which fails:
> 
> ==== [Parsing...] ==========================================================
> FILE FOUND - Including ../...../L_01_04.inc
> File '/home/jr/POVr/share/povray-3.8/include/transforms.inc' line 92:
> Parse Error:
> Cannot pass uninitialized identifier to non-optional LValue.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> that scene works fine with 10064268.alpha.
> 
> have not, so far, found the time to re-read the various newsgroup posts wrt
> 'povr' specific features and changes[*], so will probably use it just as an
> alternative to the 10064268.alpha.
> 
> [*] maybe you can put all those together, in some text file.
> 

Thanks! The first and likely the second issue(2) are the same problem.

There were updates to the code so that "make check" less often fails or 
is fooled by a previous install on the system doing the compile. Say an 
existing 'system level' functions.inc, a user setting of POVINI or 
whatever. Those changes required the introduction of a new internal only 
environment variable which when set (I think) turns off all the normal, 
nearly fanatical internal attempts to find existing .conf, .ini and .inc 
files(1) with which to run.

I screwed up the setting of the variable in the Makfile - and then 
covered up that mistake with another in the code hiding the fact I'd 
broken the normal setting of paths given I usually run with an uncommon 
POVINI setting. I believe the issue now fixed in my code.

(1) - Related. I am taking a run at no longer installing .conf and ini 
defaults in a user's HOME directory. Doing this makes it hard to run 
several POV-Ray versions side by side - though I have hacks to do it.

(2) - It might also be this second case is some actual incompatibility. 
I've made changes so more often the code will kick out the actual 
offending identifiers to make things easier to debug. On removal of old 
keywords, for example the errors should complain about the specific 
keyword. It's obviously still not reporting the identifier in your case.

Aside: Some of the bad command line flag / ini setting errors are now 
being reported too where they've long not been on unix platforms. Jerome 
added a workaround years back to kick out the command line text on 
errors, but that's less helpful than getting the more specific error text.

(*) - It's a hack at the moment, but I do have a povrTextDocumentation 
directory in the root compilation directoy which includes primarily 
areas of povr different than POV-Ray. If something exists there, it 
behaves differently in some way from the official POV-Ray. The 
exceptions to this rule in the inbuilt function changes are all 
documented in functions.inc and the density file stuff is on the wiki.

Bill P.

Post a reply to this message