On 10/13/21 10:44 AM, jr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 10/9/21 3:49 AM, jr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>>> On 10/6/21 5:01 AM, jr wrote:
>>>> This a bug is basically the same as the radiosity file append bug.
>>> a known issue, ok. thanks.
>> No. Well, it perhaps now is.
> good, I think. :-)
>> I've not spent much time with POV-Ray's IO code.
> sounds like opening a can of worms, only to find a multi-pack of can of worms
> inside.. think it .. bad not to have access to (tech) notes dealing with design
> etc of the "new" IO class. bazaar, huh?!
> coincidentally, have just posted a new macro in p.text.scene-files, 'Filed()', a
> CSV file handler, hope you'll find that useful when "stirring the worms" ;-).
Thanks jr, I'll use it do some testing.
--- An update
+ Using 'if ((fid != nullptr) && (*fid))' is frequently proving useful.
+ My additional concern in radiosity.cpp's Save was justified. We are
sometimes running the Save() code per render block(1) - without
complaint from POV-Ray - when we in fact don't have a valid file handle.
This particular issue is fixed in povr.
+ In many places finding the IO checking to be correct, which is good
news. The less good news is, in a number of those situations, the code
to generate messages for the end user is commented out or too generic to
be of much help(2).
+ Unfortunately, we are often failing in complete silence. Stuff
sometimes runs cleanly to all appearances, when there are in fact user
file specification issues.
+ With povr, I've checked in a set of updates to add and/or improve
warning/error messages both where the file IO checking was OK and where
it was not. For example, I made changes to the previous randiosity.cpp
samples file fix so that we now generate messages related to the
radiosity samples file usage.
+ I think I now understand some of what changed v3.7 to v3.8 to
introduce issues with the fopen keyword and invalid files.
+ I've got doubts about getting everything scrubbed anytime soon. Given
the code (the IO class usage) is different file to file, use to use over
a large code base. I don't currently see any easy way to flag potential
problems aside from trying things and reviewing code.
(1) - Yep, and with this, we picked up a related puzzle with radiosity.
Parts of the samples related code is running all the time! Meaning
whether we have radiosity in the scene or not, whether the quality level
supports radiosity or not - this samples code runs for each render
block. The 'additional radiosity concern,' fixed now in the povr branch,
extended what code was always run due testing for only != nullptr
(testing true for a valid file handle). A puzzle / optimization for
(2) - I learned yesterday the state file location is derived from the
output image location! I wrongly thought the state file (aka continue
trace log) was always local to where the render command was issued, but
it ends up wherever you write the output image file. Further, if your
output image location is bogus, the error message seen relates to the
state file and not the output image file - which is confusing. I changed
the error messages in a way which I hope will help.
Post a reply to this message