|
|
|
|
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 9 Feb 2022 13:16:25
Message: <620404f9$1@news.povray.org>
|
|
|
| |
| |
|
|
On 2/8/22 09:25, jr wrote:
> when will/can you make this available?
I'm aiming for March, but these fork information hooks are not yet even
checked in. It's all the first pass at something I think workable and I
fully expect to further polish the include file header and clean up the
modified code.
That said, I've begun doing some sanity checking that performance
related changes implemented over the past few months, hold for the -o3
-ffast-math -march=native and configure --enable-lto compiles where I
intend to use my povr branch personally.
The --enable-lto option, especially, is too painful to use during day to
day development, but I certainly want to use it when really rendering
scenes.
I've done a fair bit to slow povr code down too in fixing bugs and
adding options. Trying too, to check none of those cause too much slow
down as compiled and linked for real use.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 9 Feb 2022 20:21:01
Message: <6204687d$1@news.povray.org>
|
|
|
| |
| |
|
|
On 2/9/22 13:16, William F Pokorny wrote:
> On 2/8/22 09:25, jr wrote:
>> when will/can you make this available?
>
> I'm aiming for March, but these fork information hooks are not yet even
> checked in. It's all the first pass at something I think workable and I
> fully expect to further polish the include file header and clean up the
> modified code.
>
Attached is a refinement of the forkversionhook.inc file. The more I
thought about Bald Eagle's idea of versioning, the more I came to
believe his "do versioning now" idea a good one. Previously, I basically
had a release/tarball count, but that could easily change.
So, this version adopts and defines POV-Ray's Major, Minor, Revision,
Patch set up as creates a new povr release/tarball counter for it's
simpler 'version' number. Code wise, I also moved the value definitions
into version.h alongside POV-Ray's normal versioning. That version.h
file already also defines well what the values mean.
For the code check in I'm about to do there will be no difference
between povr's minor version and the tarball count (next is 6). All the
other values are currently 0. Of course the earlier five povr tarballs
have none of this fork hook code.
Bill P.
Post a reply to this message
Attachments:
Download 'forkversionhook.inc.txt' (5 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> Feedback? Thoughts?
only a couple of "things". (sorry took a few days)
I (still) think that the .inc would be a good place to store other
'povr'-specific stuff too, like the ids.
from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
hoped for a 'version.inc' which would work regardless, for any version and/or
fork of POV-Ray.
lastly, the constant + macro names are, um, a little verbose? :-)
thanks.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 14 Feb 2022 19:43:35
Message: <620af737$1@news.povray.org>
|
|
|
| |
| |
|
|
On 2/14/22 10:57, jr wrote:
> hi,
>
> William F Pokorny<ano### [at] anonymousorg> wrote:
>> Feedback? Thoughts?
> only a couple of "things". (sorry took a few days)
No worries.
>
> I (still) think that the .inc would be a good place to store other
> 'povr'-specific stuff too, like the ids.
>
Here, I wonder if perhaps the scale of change in the povr branch is
being seen as less extensive than it in fact is. The new setidtypes.inc
is one of several completely new include files.
Nearly all the remaining, shipped include files are substantially
different. Only rand.inc hasn't been changed much - mostly because I see
a good many puzzles there in code that I don't think many use. I'm not
sure what to do povr's current rand.inc as yet.
The povr branch only ships 14 includes - to be 15 with forkversionhook.inc.
Lastly, an aim is that the 'forkversionhook.inc' file be extensible.
That, in approach, its able to accommodate multiple forks / patches /
branches. In other words, in just supporting multiple forks over time,
it could grow substantially in size. I see no reason this file cannot be
shared - at least to some degree - across forks.
> from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
> hoped for a 'version.inc' which would work regardless, for any version and/or
> fork of POV-Ray.
I'll try to reduce / rework the mentions of povr.
The current forkversionhook.inc does work for any POV-Ray version - at
least when I've tested it.
It's only povr specific when the SDL variable Dump_povr_fork_ is set on
inclusion. Then it prints documentation as to what povr fork_*()
constants are available and stops - and it only does that much if the
fork being run is in fact 'povr'. I'll add a commented #debug where I
had an empty else block indicating something which could be printed when
the fork hook is not found. It's commented because I don't want to
default to always printing something on inclusion of
forkversionhook.inc. Regular include use will be to make the
'Have_f_odd_fork_hook()' macro available to scene code and nothing more.
> Have_f_odd_fork_hook()
> lastly, the constant + macro names are, um, a little verbose?:-)
>
Agree.
In general, I think I'll reduce the f_odd() visibility. No reason day to
day users need to know this the internal 'hook'.
I also think you're right it's better to call the fork_*()s, constants,
rather than functions.
Beyond that I'll take you to mean, perhaps, something like the following:
forkversionhook.inc --> forkhooks.inc ?
Have_f_odd_fork_hook() --> HaveForkConstants() ?
Dump_povr_fork_ --> Fork_povr ?
...I'm less a fan of shortening the constant pairs, but...
fork_str(n) --> frkstr(n) ?
fork_val(n) --> frkval(n) ?
Better?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/14/22 10:57, jr wrote:
> > ...
> > I (still) think that the .inc would be a good place to store other
> > 'povr'-specific stuff too, like the ids.
> >
>
> Here, I wonder if perhaps the scale of change in the povr branch is
> being seen as less extensive than it in fact is. ...
> In other words, in just supporting multiple forks over time,
> it could grow substantially in size. I see no reason this file cannot be
> shared - at least to some degree - across forks.
yes there is much divergence, and I had not thought "forward", ie after a number
of subsequent releases, so scratch the thought. (I focus perhaps too much on
"everything in one place", anyway)
> > from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
> > hoped for a 'version.inc' which would work regardless, for any version and/or
> > fork of POV-Ray.
>
> I'll try to reduce / rework the mentions of povr.
>
> The current forkversionhook.inc does work for any POV-Ray version - at
> least when I've tested it. ...
> I'll add a commented #debug where I
> had an empty else block indicating something which could be printed when
> the fork hook is not found. It's commented because I don't want to
> default to always printing something on inclusion of
> forkversionhook.inc. Regular include use will be to make the
> 'Have_f_odd_fork_hook()' macro available to scene code and nothing more.
works as in parses, but (empty else branch) no feedback when it isn't povr. I
think that I'd hoped for a situation where POV-Ray proper and (eventually) all
forks supply a version.inc which tells, basically, whether or not "official";
forks, and POV-Ray, are then free to add constants and or macros to probe
further.
> > Have_f_odd_fork_hook()
> > lastly, the constant + macro names are, um, a little verbose?:-)
> ...
> Beyond that I'll take you to mean, perhaps, something like the following:
>
> forkversionhook.inc --> forkhooks.inc ?
>
> Have_f_odd_fork_hook() --> HaveForkConstants() ?
:-) 'forkversion.inc', actually. it's the "hook" that's .. surplus in my view.
I don't mind the underscores, think they aid readability.
> ...I'm less a fan of shortening the constant pairs, but...
>
> fork_str(n) --> frkstr(n) ?
> fork_val(n) --> frkval(n) ?
>
> Better?
ouch! personally (if it mattered) 'fork_{str,val}' is fine, though I'd probably
write 'fork_{key,val}'.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
just to clarify.
> ...
> think that I'd hoped for a situation where POV-Ray proper and (eventually) all
> forks supply a version.inc which tells, basically, whether or not "official";
I don't mean official as in compiled-by. "official" returned from a version.inc
would tell me that the scene's SDL will work as detailed in the official
wiki/docs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> Lastly, an aim is that the 'forkversionhook.inc' file be extensible.
> That, in approach, its able to accommodate multiple forks / patches /
> branches. In other words, in just supporting multiple forks over time,
> it could grow substantially in size. I see no reason this file cannot be
> shared - at least to some degree - across forks.
It's just a text file. And it's for POV-Ray - so just how many edits and forks
there will be .... I mean, even if it was War & Peace in ASCII, it still
wouldn't be that large of a file.
A functional option, one I'm not sure I like ATM, is to have a version
_directory_ with a tree of inc files that the main file includes and executes -
only if they exist. Then the individual users can grow or prune the contents
of the directory as they see fit. Still think that for any given fork, a
generic named file should call the most recent name-with-version.inc
That way people can search the forums (fora?) and easily see if they have the
proper/latest version of what they're looking for. Even if it's just File1,
File2, File3 .... it at least makes the filename different, and gives an
easily identifiable sequential progression.
> In general, I think I'll reduce the f_odd() visibility. No reason day to
> day users need to know this the internal 'hook'.
You can have silent and verbose modes.
Silent is for everyday use, verbose can be for anyone looking to figure
something out. Just set a flag, look for the presence of a dummy file...
As for constant, function, and macro names, there's a school of thought that if
your names are descriptive enough, the code is "self documenting" and doesn't
require comments. I think this works well for code that isn't long on the
first few (re)write(s) and only gets edited every so often. Using long names
in day to day use is a DRAG.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 16 Feb 2022 06:22:44
Message: <620cde84@news.povray.org>
|
|
|
| |
| |
|
|
On 2/15/22 02:11, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> just to clarify.
>
>> ...
>> think that I'd hoped for a situation where POV-Ray proper and (eventually) all
>> forks supply a version.inc which tells, basically, whether or not "official";
>
> I don't mean official as in compiled-by. "official" returned from a version.inc
> would tell me that the scene's SDL will work as detailed in the official
> wiki/docs.
>
Thinking.
Nobody can truly declare particular behavior without being the one
providing a pre-compiled POV-Ray package. Further, the compiled program
needs to be linked with, or use, fixed library dependencies. The
official status is indicated by the POV-Team only for windows binaries
where the current libraries are part of the git tracked code base.
Those binaries only state official status in the text output while
setting up the parser to die on the 'unofficial' keyword. There isn't a
way to query official / unofficial status from within the SDL.
We want to be able to set up scenes / includes with conditionals so we
can run compiles from nominally unmodified source alongside forks like
povr. This rules out the use of the 'unofficial' keyword for starters.
We also want something like 'unofficial' which dies for non-windows
POV-Team provided binaries where we know the code will only run with a
given fork(2).
I didn't call 'forkversion.inc' 'version.inc' to allow for an official
POV-Team shipped 'version.inc'.
I suppose OK for forks to provide 'version.inc' files ahead of it
potentially existing in POV-Team releases. Attached two povr include
files in 'version.inc'(1) and 'forkversion.inc'. The latter with
additional updates - shorter names, rewording, etc.
Comments welcome.
Aside: I'm unsure when / if to change the povr code to force all
incoming SDL to run strictly at v3.8+. Internally, I've slowly been
tossing code for backward compatibility into the bit bucket. V3.8+ SDL
is all I intend to support. However, as many are still working with
older releases, scenes and includes, I've been maintaining the parser in
a state that allows earlier version settings. It's useful when looking
at posted issues...
Bill P.
(1) - Uses file_exist for 'forkversion.inc' / 'version.inc', which can
be problematic in the way file_exist with includes can be. However, I
see no better method for a backward compatible 'version.inc'.
(2) - Thinking with povr I'll now use both 'unofficial' and code like:
#if (file_exists("version.inc"))
#include "version.inc"
#end
#if (!Fork_povr) // This POV-Ray SDL code requires the povr fork.
#error "This POV-Ray SDL code requires the povr fork."
#end
Post a reply to this message
Attachments:
Download 'version.inc.txt' (4 KB)
Download 'forkversion.inc.txt' (5 KB)
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 16 Feb 2022 06:38:40
Message: <620ce240$1@news.povray.org>
|
|
|
| |
| |
|
|
On 2/15/22 07:07, Bald Eagle wrote:
> It's just a text file.
True. It's also an include which the parser must digest. With animations
the parser eats all includes, again, for each frame. Though users often
include .inc files by the handful(1), being more selective about what
needs to be included is more efficient.
I'll let your other ideas and thoughts bang around in my head for a while.
Bill P.
(1) - Via stdinc.inc as often as not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> There isn't a
> way to query official / unofficial status from within the SDL.
yet.
> We want to be able to set up scenes / includes with conditionals so we
> can run compiles from nominally unmodified source alongside forks like
> povr. This rules out the use of the 'unofficial' keyword for starters.
>
> We also want something like 'unofficial' which dies for non-windows
> POV-Team provided binaries where we know the code will only run with a
> given fork(2).
>
> I didn't call 'forkversion.inc' 'version.inc' to allow for an official
> POV-Team shipped 'version.inc'.
chain-loading via 'file_exists()' is nice + "clean" (imo).
> ...
> Comments welcome.
>
> Aside: I'm unsure when / if to change the povr code to force all
> incoming SDL to run strictly at v3.8+. Internally, I've slowly been
> tossing code for backward compatibility into the bit bucket. V3.8+ SDL
> is all I intend to support. However, as many are still working with
> older releases, scenes and includes, I've been maintaining the parser in
> a state that allows earlier version settings. It's useful when looking
> at posted issues...
it would be interesting to see proposals for an updated v4+ SDL.
out of interest, how difficult would it be to have two separate parsers? one
for pre 3.7/8 compatibility, one for newer style. (I'm guessing that the
executable would not be all that much larger, and separation might bring other
benefits)
have only spent a few minutes looking over the attached, seem ok (bar copy/paste
typos 'str_var' in 'forkversion.inc'.)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|