|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/8/21 7:06 PM, Tor Olav Kristensen wrote:
>...
> 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... ;-)
That's good.
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 ?
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.
> >> Suppose I could compare to forms in skvectors?
> >> ...
> >
> > I'm not sure what you mean here.
>
> 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.
> For reference I'm shipping only the following includes as 'core' ones in
> the povr branch.
>
> arrays.inc
> functions.inc
> math.inc
> rand.inc
> shapes.inc
> strings.inc
> transforms.inc
>
> Limit your look to these files for my participation. Further, I have on
> my list to move some of the macros in these to munctions.inc or other
> include files as 'not core' related / not commonly used.
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.
Other macros demonstrate bad programming practice and/or are made in an
intricate way so that they require a lot of effort to redo in a proper way. I'm
reluctant to spend much time on those in the beginning.
Further, there are some macros that there should be no need for (because there
are better ways to do things), and others that there will very seldom be a use
for (or as you say: they are not commonly used).
Then there are macros that could be made simpler and/or more mathematical
efficient/robust/accurate.
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.
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.
Some macros are so intricate and so influenced by its creator intricate way of
thinking that I'm having problems understanding what these macros are good for.
And they may be tightly coupled to other macros that do things in non-optimal
ways. I would suggest that the rewrite and inclusion of those is postponed until
we have decided if they really are useful or need.
Some macros use dubious (or obfuscated) "tricks", that are possible in the SDL,
just to save some characters or lines of code. Those can be quite difficult for
new users to understand. I suggest that those "tricks" should be saved for
problems where there are no other good ways to solve the problem.
Then there are macros that use syntax that are legal - and useful for those that
are a bit lazy or sloppy. But often they are not very educational. E.g. "scale
2", "#if (1)" or "ambient 0.2". These should be fixed so that it is easy for new
users to understand what is really going on.
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.
> arraycoupleddf3s.inc - This temporarily needed as it goes with some DF3
> related work I did years back which is in the povr branch. Some of it
> should end up in arrays.inc; some of it should go away. I've not sorted it.
Ok. I can't remember if I have seen that file.
> Aside: My belief is future POV-Ray ray needs to move to a support
> structure which breaks things into core-code, scenes, includes,
> documentation, ini/configs, helper scripts / programs, (fonts?) and the
> web site (also the wiki?) as independent code control structures on
> github say ideally all with different primarys though perhaps still
> common POV-Ray owners like Chris. I think it would work better having
> multiple gate keepers to multiple POV-Ray domains. This model also
> matches to a degree what linux package developers are already going
> themselves breaking POV-Ray into multiple packages.
I think that I agree with you on this. (I'll have to read it again later when
I'm not tired.)
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.)
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
|
|
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
|
|