On 5/10/21 10:50 PM, Tor Olav Kristensen wrote:

Up front, I want to state clearly I don't speak for POV-Ray.

My povr branch is a personal one. Anyone can use any work from it under 
the POV-Ray license terms. I consider it work donated to the POV-Ray 
team and community should they have use for any part of it.

It's linux/unix only for starters, simply because I'm not a real 
programmer and I don't know windows and long not used it day to day.


>> Aside: I've been working on adding self testing to all the includes
>> (Ingo's suggestion and method) and in addition to macros I broke myself
>> with povr branch changes, Histogram, was a macro long shipped which
>> already wasn't working... ;-)
...
> I'm not sure if I have seen Ingo's suggestion for how to test the include files.
> Do you have any links to relevant threads ?
> 

None handy, but it basically adds a conditional at the very bottom of 
each include. There are variations but here is some stuff cut from my 
current functions.inc (less the line wrapping...):

//--- Self testing:  povr +mv3.8 +i<this_file>
#if(input_file_name="functions.inc")

     #fopen FID "SelfTestFunctionsInc.txt" write
     #write (FID,"\nExpect value followed by value generated.\nF_ 
prefixed are pattern/math wrapped equivalents.\n")

...
     // f_radial
     #write (FID,"\n---\n")
     #write (FID,concat("f_radial  0.000000 
",str(f_radial(+1,+0,+0),9,-1),"\n"))
     #write (FID,concat("f_radial  0.000000 
",str(f_radial(+0,+1,+0),9,-1),"\n"))
     #write (FID,concat("f_radial  0.875000 
",str(f_radial(+1,+0,+1),9,-1),"\n"))
...
     #ifdef (F_radial) #undef F_radial #end
     #declare F_radial = function { pattern { radial raw_wave } }
     #write (FID,concat("F_radial  0.000000 
",str(F_radial(+1,+0,+0),9,-1)," (raw_wave)\n"))
     #write (FID,concat("F_radial  0.000000 
",str(F_radial(+0,+1,+0),9,-1)," (raw_wave)\n"))
     #write (FID,concat("F_radial  0.875000 
",str(F_radial(+1,+0,+1),9,-1)," (raw_wave)\n"))
...
     #write (FID,"\n")
...

     #write (FID,"\n")

     #fclose FID

     #error "\n\n===Self testing. Stop before render.===\n"

#end // End self testing

#version Functions_Inc_Temp;
#end//functions.inc

Not set in stone but, the output is in the form:

   name expect_val SDL_created_val comment

for which I created a quick and dirty scanning and report script.


> I hope that my rewrite of the Histrogram macro works ok in your branch then. I
> tried to search for demo scenes that use this macro, but I couldn't find any.
> 

I also found nothing. Not tried yours as yet.

...
>>
>> I was guessing what you have in your package would be what you consider
>> solid/better implementations numerically. However, it helps me if you do
>> the sorting of what might be better implementations of current code.
> 
> Ok. I may be able to help with that, but it will probably take weeks or months
> to go through all the macros and rewrite those that need to be improved.
> 
> If am going to spend much time rewriting a lot of macros, then I wish to dictate
> the formatting style and the naming of variables in the macros.
> 

I'm mostly OK with that, but... :-)

Again, I'm not 'POV-Ray' - so measure your efforts here knowing it's not 
me that will decide whether any of your include changes become official 
ones.

povr specific
-------------
The pink elephant in room is that, though configurable, by default povr 
limits identifiers to a-z,0-9 and _ characters. I'm trying to make 
better the argument name collision exposure of traditional SDL by making 
the long recommended rules for identifiers hard parser checks.

Not 100% sure the hard identifier checking will stick, but... When 
there, you can use _abc like arguments and not worry about accidental 
collisions. And I'm hoping we can get away from macros such as the
Vector analysis macros with all the really long identifier names.

---
The blue elephant in the room is I want to make use of inbuilt code 
where I have it available. I want to make more pure macros, "munctions", 
and this can happen only in the povr branch around inbuilt functions 
which are not completely settled.

---
The green elephant in the room with the distributions in rand.inc. I'd 
like to move to something using the distributions shipped with c++ since 
c++11, but I've not worked out how to best do it.

---
Many elephants. :-) I can work off anything you publish aimed at a more 
generic, eventual v3.8. Perhaps that's a better direction for your work?

> 
>> For reference I'm shipping only the following includes as 'core' ones in
>> the povr branch.
...
>> Limit your look to these files for my participation. 
...
> 
> Ok.
> 
> I have noticed at least one macro that duplicates the functionality of another
> macro (I suspect that the author was not aware of that) - and there might be
> more such macros.

I know there are multiple interpolation macros(1) - and probably others.

(1) - One is outside the core set I think.

> 
...
> 
> New features in v3.8 will make it possible to rewrite macros that do things in a
> "clumsy" way (because of earlier limitations in the language) to versions that
> work in a more "elegant" and educational way.

Agree.

> 
> The documentation inside the files for some macros are quite imprecise and
> therefore need rewriting. Perhaps most of the documentation in the include files
> should be moved into a document or to a web page that we refer to inside the
> include files.
> 
...
> 
> There may be so many changes to the macros in the include files that I suggest
> that we make new include files with new names which we move the good and fixed
> macros into. The old files can then be left as legacy include files with their
> old file names. We could then write that these include files are not recommended
> for new scenes made with POV-Ray versions after v3.8.
> 
...

> I see now that I have been a bit brutal in my description of the current state.
> Sorry about that.

No issues here. I agree with everything you've said - and might even say 
more. :-) But, here too I need to make clear my povr branch breaks 
compatibility with many old scenes. Not so much in the parser where I'm 
trying to stick with v3.8's aim - except for the lower case identifiers 
but with other features / inner workings.

> 
>> arraycoupleddf3s.inc 

It's an include published along with DF3 documentation on put up on the 
wiki now quite a few years ago. Consider it povr specific though it was 
originally written to work with v3.7 or v3.8.

> 
> If some include files are deemed to not be 'core', they could be moved into
> another git repository that are maintained "on the side". (Perhaps you just
> wrote that in the section above.)
> 

Yes, that's exactly the idea. :-)

Bill P.

Post a reply to this message