hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/27/22 10:54, jr wrote:
> > where/how does 'patch_str' get used?
>
> What I was thinking about was more like:
>
> #declare povr     =  0;
> #declare povr_ver = -1;
> #if (99 = f_odd(0,0,0,99))
>      #if (!strcmp(patch_str(0),"povr"))
>          #declare povr = 1;
>          #declare povr_ver = patch_val(0);
>      #end
> #else
>    ...
> #end
>
> The patch_str() and patch_val() would be paired by count. I am leaning
> this way because the parser is set up for keywords to always be of one
> type.
>
> Having the pair makes it easy to set up a loop to pull more than one key
> value pair aimed at creating, say, a table.

ok, key/value pairs.  thanks for code example (I find "snippets" helpful).  re
my earlier post, that testing and the "cloaking" of 'internal(43)' hidden,
perhaps, behind a "friendlier" bool macro/variable.


> ...
> >
> > from my admittedly limited vantage I see no downsides, other than that
> > 'functions.inc' (presumably) would need to be sourced.
> >
> > [*] also .. pleasing that a function with that exact name should get shouldered
> > with this odd job.:-)
>
> Indeed! :-)

what was its original purpose?  reading that the argument is a "field strength"
made me wonder whether it's anything to do with 'blob's.


> ...
> We only include functions.inc to declare - create global symbol table
> entries - for each inbuilt function name. For f_odd we could, and
> probably should, use(b) just:
>
> #declare f_odd = function { internal(43) }
>
> ahead of the call to f_odd.

that could/would be the content of a 'version.inc'.


> ...
> > a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> > changed stuff ("amplify") as well as version/patch level, everything in one
> > place.:-)
>
> Yes, good idea. Putting more in include(s) that creates a dictionary for
> such information would be better / easier. The include could itself
> could test the forked version / branch of POV-Ray matches its internal
> information. Hmm, we could create csv file(s) and use table.inc though
> guess I'm not sure if more or less work/value over just creating the
> dictionary straight up?

'table.inc'?  :-)  guess you were thinking 'filed.inc'?  what do you think of a
'version.inc' which, for variants like 'povr', would simply pull in another
include if/where required?


> On automatically including includes, I lean against it.

v much agree.


> ...
> Maintaining this per feature versioning is something I think works
> better where a coder is working on say only a few of modules for a
> larger project/tool. I don't have the bandwidth to support anything
> complicated like maintaining multiple user select-able versions, but I
> might be able to increment some version number per keyword to at least
> indicate something changed related to the keyword/option.
>
> I'll think more about what to do versioning wise, what I might be able
> to maintain...

fwiw, I do not think that it has to be very .. fine-grained, necessarily.  as
long as a user me can establish, in-scene, that the executable supports this
feature or another as easy to use (in conditionals) test(s).


regards, jr.

Post a reply to this message