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.
Post a reply to this message