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

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

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

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)

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