Hi folks,

there's other stuff that needs to be done, which should be easy to 
delegate, at least partially:

During my absence, I gather other people have stepped up and done some 
error diagnosis and coming up with fixes. At least Bill's name has come 
up a couple of times.

Now, if we want those fixes to make their way into official POV-Ray, 
some steps need to happen - all essentially boiling down to getting the 
information to a place and into a format where it can be more easily 
managed:


(1) Information on errors not yet diagnosed, currently spread across 
countless threads on multiple newsgroups, needs to be collected in one 
central place, where the status of each issue can be easily tracked and 
updated, and the error itself easily referenced.

Before I went hiding, the ideal place for that was the Issues section on 
GitHub (https://github.com/POV-Ray/povray/issues).

If you want to help me help you help us all and get those bugs fixed, I 
guess that's still the best place. I don't currently have the energy to 
dig through old threads and sift the information out there, but I guess 
some of you folks could help out with that.

Ideally, the prcess of collecting that information would involve 
"distilling it down" to a simple test case, with a minimalistic scene 
and concise description. Plus a link to the newsgroup thread for reference.


(2) In a similar vein, information on errors already diagnosed, but 
still without a suggested solution, also need to be collected and 
"distilled".

Again I would suggest the issues tracker on GitHub. I'd recommend to put 
the description of symptoms into the issue description proper, and add 
the diagnostic findings as a comment.


(3) For errors that have been diagnosed, and for which a solution has 
already been found, it might need to be wise to also add them to the 
issue tracker. More importantly, however, the solution has to be placed 
in a place and into a form that makes it easy to "import" it into the 
POV-Ray codebase.

Before I went hiding, the ideal format for that would have been a Git 
Pull Request.

I'm aware that might not be everyone's favorite format, but maybe you 
folks can team up, with someone producing diffs and someone else 
bringing them into Git? (I myself am terrible at working with diffs, so 
don't expect me to touch them except with a 10 foot stick.)

A single pull request per issue would be preferable, and changes should 
be based on a recent version from the master branch.


Two important things I'd like to note:

(A) Make sure to coordinate with others, in case there's more than one 
person to pick up this gauntlet.

(B) Be prepared for feedback that may sound rejecting - it is generally 
not meant that way. Whoever will review the error report or proposed 
solution _will_ be thankful for the time and effort you're putting into 
it. And they _will_ be even more thankful for any _additional_ time and 
effort you might be willing to give in case they find a snag with the 
proposed solution. Software developers just generally tend to not be 
very good at conveying such sentiments.


Am I scaring you away already?
I hope I'm not.

I'm grateful for anyone willing to put time and effort into this, so 
that POV-Ray v3.8 gets the bugfixes it deserves. Every little bit helps.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> there's other stuff that needs to be done, which should be easy to
> delegate, at least partially:
>
> During my absence, I gather other people have stepped up and done some
> error diagnosis and coming up with fixes. At least Bill's name has come
> up a couple of times.
> ...
> (3) For errors that have been diagnosed, and for which a solution has
> already been found, it might need to be wise to also add them to the
> issue tracker. More importantly, however, the solution has to be placed
> in a place and into a form that makes it easy to "import" it into the
> POV-Ray codebase.
> ...
> I'm aware that might not be everyone's favorite format, but maybe you
> folks can team up, with someone producing diffs and someone else
> bringing them into Git? (I myself am terrible at working with diffs, so
> don't expect me to touch them except with a 10 foot stick.)
> ...
> I'm grateful for anyone willing to put time and effort into this, so
> that POV-Ray v3.8 gets the bugfixes it deserves. Every little bit helps.

I can provide three patches if thought useful.  the following clipped from the
build script:

# note p.bugreports: WFP 13.8.2020 "alpha.10064268 undef behaviour".
patch --verbose -p0 < ${CWD}/patch20200813
# note p.general: WFP 19.9.2020 "povray vs uberpov am3".
patch --verbose -p0 < ${CWD}/patch20200919
# note p.beta-test: WFP 21.4.2021 cf ingo, dict copy.
patch --verbose -p0 < ${CWD}/patch20210421

(I think there's at least one more "already fixed" for which I didn't make one)


regards, jr.

Post a reply to this message

Am 05.06.2021 um 01:03 schrieb jr:

> I can provide three patches if thought useful.  the following clipped from the
> build script:

Probably.

Beware that when collecting patches, it is my understanding that they 
only work if the file in question hasn't been changed otherwise, so it 
would be important to note what version of POV-Ray they were designed for.

In this particular case, it seems rather evident though that it would be 
alpha.10064268.

> # note p.bugreports: WFP 13.8.2020 "alpha.10064268 undef behaviour".
> patch --verbose -p0 < ${CWD}/patch20200813
> # note p.general: WFP 19.9.2020 "povray vs uberpov am3".
> patch --verbose -p0 < ${CWD}/patch20200919
> # note p.beta-test: WFP 21.4.2021 cf ingo, dict copy.
> patch --verbose -p0 < ${CWD}/patch20210421

Post a reply to this message

Am 04.06.2021 um 22:13 schrieb clipka:

> Now, if we want those fixes to make their way into official POV-Ray, 
> some steps need to happen - all essentially boiling down to getting the 
> information to a place and into a format where it can be more easily 
> managed:

By the way, one thing that makes this all the more helpful, is that 
newsgroup messages posted during my hiatus until somewhen in 2020 are 
currently cumbersome to access for me, as the news server refuses to 
tell me what's written in them.

(No, re-scanning the headers doesn't solve the problem, it only makes it 
worse. Which is why in a few select newsgroups I have lost any trace of 
messages between late 2018 and early 2020 entirely, even the header 
information.)

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.06.2021 um 01:03 schrieb jr:
>
> > I can provide three patches if thought useful.  the following clipped from the
> > build script:
>
> Probably.
>
> Beware that when collecting patches, it is my understanding that they
> only work if the file in question hasn't been changed otherwise, so it
> would be important to note what version of POV-Ray they were designed for.

yes.  I do use version specific sub-directories, so stuff is always kept
together.

note that I have not included another, older patch for alpha.10064268.  from
19.2.2019, correcting missing 'std::' prefixes (but you released a newer version
for that).


regards, jr.

Post a reply to this message

Attachments:
Download 'cl-patches.tar.xz.dat' (1 KB)

"jr" <cre### [at] gmailcom> wrote:
> ...
> note that I have not included another, older patch for alpha.10064268.  from
> 19.2.2019, correcting missing 'std::' prefixes (but you released a newer version
> for that).

>> By the way, one thing that makes this all the more helpful, is that
>> newsgroup messages posted during my hiatus until somewhen in 2020 are
>> currently cumbersome to access for me, as the news server refuses to
>> tell me what's written in them.

<http://news.povray.org/povray.beta-test/thread/%3C5c6b8351%241%40news.povray.org%3E/>

(forgot..)


regards, jr.

Post a reply to this message

I can make a very small scene to demonstrate the issue with the radial pattern,
although I think the extant thread is kinda self-explanatory, and WFP agrees
with the proposed mathematical solution.

All the other things have to deal with source code I haven't looked through or
would likely be able to competently suggest code solutions for.

So here is a list of what I have found / can remember:

creating an array of arrays, and then trying to access an uninitialized element
of that data structure.
https://news.povray.org/5b83c8ab%241%40news.povray.org


A declare without the leading # works
http://news.povray.org/povray.general/thread/%3Cweb.5d8f1cd3fe1f4a21e462584c0%40news.povray.org%3E/?mtop=428173&moff=5

radial pattern
http://news.povray.org/web.5dabcdf0e43f3c684eec112d0%40news.povray.org

suggested fix (coded in SDL function syntax)
#declare Angle = function (XX,ZZ) {atan2 (XX, ZZ)-(pi/2)}
#declare Adjusted = function (XX,ZZ) {select (Angle(XX,ZZ),  Angle(XX,ZZ)+tau,
Angle(XX, ZZ))}
#declare FreqPhase = function (XX, ZZ, F, P) {mod ((P*tau+Adjusted (XX, ZZ))*F,
tau)/tau}
#declare Radial = function (XX, ZZ, F, P) {select (XX*ZZ,  FreqPhase
(XX,ZZ,F,P), 0, FreqPhase (XX,ZZ,F,P))}


project some light through an image
map
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5d101e19377950ae4eec112d0%40news.povray.org%3E/

blend_gamma typo
http://news.povray.org/povray.beta-test/thread/%3C6022887b%241%40news.povray.org%3E/

Icosahedron include
http://news.povray.org/povray.binaries.images/thread/%3C87muh7xgh9.fsf%40munyer.com%3E/?ttop=429414&toff=50

dictionary crash
http://news.povray.org/povray.general/thread/%3CXnsAD0BC42BCF8Aseed7%40news.povray.org%3E/?mtop=433766

normals
http://news.povray.org/povray.binaries.images/thread/%3C5f830726%40news.povray.org%3E/

spiral patterns
https://news.povray.org/5f6c87f2%241%40news.povray.org

no_image
https://news.povray.org/povray.general/thread/%3Cweb.5e7944321f97b21e393d37fe0%40news.povray.org%3E/?ttop=430126&moff=8


cutaway_textures
https://news.povray.org/web.5e3385d55a7390894eec112d0%40news.povray.org

There may be a few others.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> There may be a few others.

Don't know enough about the details, but am placing this here due to the
potential issues with the current implementation of parse_string

http://news.povray.org/608967ad%241%40news.povray.org

RL slowing me down, so input and output maybe be sparse.

Post a reply to this message