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