Aside: New thread as original not recovered after the crash with respect 
to the news server itself, which leaves Thunderbird unable to continue it.

Ref:

https://news.povray.org/povray.beta-test/message/%3C5bdf75ab%241%40news.povray.org%3E

[insert long back story here] ... My thinking was the ini include 
searching of the library path was working fairly well despite what some 
had said.

I recently re-enabled the parsing of a users local povray.ini and 
povray.conf files stored in $HOME/.povray/3.8

Turns out. If the ini file you want isn't in your local directory - and 
the library path where it exists isn't the first listed in the reported 
library paths parsing cannot find it and dies.  :-(

The only immediately useful thing for those with $HOME/.povray 
povray.ini files, you can use the shipped ini files if you change:

     Library_Path="__POVLIBDIR__"
     Library_Path="__POVLIBDIR__/ini"
     Library_Path="__POVLIBDIR__/include"

to

     Library_Path="__POVLIBDIR__/ini"
     Library_Path="__POVLIBDIR__"
     Library_Path="__POVLIBDIR__/include"

With that change I'm able to run the following (reminder yuqk is 
linux/unix only):

     yuqk playpen.pov include_ini="quickres.ini[1024x768, AA 0.3]"

or

     yuqkZ playpen.pov +ini"quickres.ini[1024x768, AA 0.3]"

Of course, with that set up you can then only reach local directory ini 
files afterward because those are all that will be found.

I was getting fooled as to the state of things. I mostly run without 
$HOME./povray local povray.ini and povray.conf file. So, when I added 
the ini included directory to the library path files, things worked - 
because that path happened to be the first in the list of library 
directories.

Bill P.

Aside(2): The yuqk fork itself does not ship the ini directory of files 
at present. They existing ones are very much out of date.

Post a reply to this message

On 3/20/24 01:49, William F Pokorny wrote:
> With that change I'm able to run the following (reminder yuqk is 
> linux/unix only):
> 
>      yuqk playpen.pov include_ini="quickres.ini[1024x768, AA 0.3]"
> 
> or
> 
>      yuqkZ playpen.pov +ini"quickres.ini[1024x768, AA 0.3]"
> 
> Of course, with that set up you can then only reach local directory ini 
> files afterward because those are all that will be found.

First, as an addition to the previous post, I should have added as a 
footnote that using include_ini= (*) or +ini with a full path or 
complete relative path specification for ini files works.

Today. These options are in fact the only way other than copying all the 
ini files you need into the local rendering directory to be sure(**) you 
find ini files (other than install or user-local povray.ini) correctly.

(*) - The include_ini= option exists today in official releases, but 
isn't documented.

(**) - This isn't the same as saying the current ini mechanism doesn't 
often work. Of course, this is an ugly position to be in as it means the 
ini behavior, where other than having all same directory ini file(s), is 
unreliable.

---

The above said, the aim of this post is to document that I've found 
issues with ini parsing error reporting when ini files are directly 
included! :-(

(Yes, now guessing that, not documenting 'include_ini=' might have been 
some sort of a 'delay for fixes' which never happened.)

Basically, ini files included via this mechanism can have serious 
parsing issues which end up completely ignored in official releases of 
POV-Ray (Linux / Unix versions at least). They are 'somewhat ignored' 
with current releases of the yuqk fork.

The yuqk fork reports the parsing problems with additional text messages 
where official releases usually don't. However, today in released yuqk 
versions up to R13, the parsing still doesn't stop on finding serious 
issues. The bad error return code gets eaten / overwritten due how the 
include_ini= option was originally implemented.

---

Because it's part of the 'ini' tofix pile and related, I'll toss out 
again that the ini directory ordering, as affected by library paths, is 
glitch-y. We should not be using the library search paths for ini files 
at all, but rather only for include files.

It believe it should always have been another path set up mechanism for 
ini files (perhaps an INIPATH env var similar to PATH?). Or, no path 
searching at all and just include_ini= or +ini usage. This latter 
approach is how I plan to go with yuqk - though I've not yet worked out 
the code changes to disable to sometimes searching of the library path 
for ini files, so we'll see.

Bill P.

Post a reply to this message

On 4/15/24 22:49, William F Pokorny wrote:
> The above said, the aim of this post is to document that I've found 
> issues with ini parsing error reporting when ini files are directly 
> included!

I believe these issues now fixed in the upcoming release R14 of yuqk.

> ...
> Because it's part of the 'ini' tofix pile and related, I'll toss out 
> again that the ini directory ordering, as affected by library paths, is 
> glitch-y. We should not be using the library search paths for ini files 
> at all, but rather only for include files.
> 
> It believe it should always have been another path set up mechanism for 
> ini files (perhaps an INIPATH env var similar to PATH?). Or, no path 
> searching at all and just include_ini= or +ini usage. This latter 
> approach is how I plan to go with yuqk - though I've not yet worked out 
> the code changes to disable to sometimes searching of the library path 
> for ini files, so we'll see.

And with the library paths in v3.8+ onward(*); the problem with the ini 
search mechanism only picking up the first search directory in the set 
has been fixed for release R14 of yuqk.

While there are other fixes / changes in yuqk besides, I 'think' much 
can be had in official v3.8+ POV-Ray releases by simply adding the line:

   libpath.clear();

just ahead of:

   if (POVMSAttr_GetUTF8String(&item,kPOVMSType_UCS2String,libpath) != 0)

in:

   ITextStream *ProcessRenderOptions::OpenINIFileStream(...)

in the file:  source/frontend/processrenderoptions.cpp

Things go wrong in POVMSAttr_GetUTF8String() and the collection of 
functionality it calls in that the individual paths returned after the 
first are mangled / blended with prior results.

I've kept the now working library path searching in yuqk rather than 
create an alternate approach / method for it - though I think any 
eventual v4.0 offering should set up a separate 'ini path'.

(*) - The v3.8+ code is different than the v3.7 code. Unsure how v3.7 
works with respect to ini files and searching the specified library path.

Bill P.

Post a reply to this message