|
|
On 1/27/22 10:54, jr wrote:
jr & Bald Eagle, Thanks both for the feedback and ideas.
> gut reaction[*] - yes, something along that line. while compatibility is
> important of course, I think that this mechanism is of value only from current
> versions on. not quite sure I really understand the detail, so I'd write eg:
>
> #if (99 = f_odd(0,0,0,99))
> #if (!strcmp(patch_val("id"),"povr"))
> ...
> #end
> #else
> ...
> #end
>
> 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.
Using a count for access, I believe, will make it a little less likely
users will get the feature tangled up on string specification or
interpretation.
Though, nothing would stop any given branch developer from setting up to
pull values out of returned strings in the SDL - if that's the set up
they want.
>
> 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! :-)
Yes, including functions.inc is a bit clunky and it touches on the
parser performance issue I was trying to address somewhat with my
'munctions' (macro call defined functions) idea - a little work toward
which showed up in my last release.
True to some degree for any include, but when we pull in functions.inc
in particular we define upwards of one hundred symbols in a symbol
table. These can and do collide by hash value(a) which slows down
functions at RUN time as well as slowing general parsing at parse time.
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.
This selective declaration of inbuilt functions has always been
recommended against because the positional values in the internal
function table might change. True, but, they haven't actually changed in
a very, very long time - until povr really. There has always been a
performance reason to do the declares for only the functions in
functions.inc you use(c).
(a) - This especially true in official POV-Ray where the hashing
mechanism, though itself very fast, generates hash values heavily
weighted / bunched around the first token character. The povr branch
uses a C++ provided string hashing with very good hash value
distribution - even where strings are quite similar (Fn00,Fn01...). The
C++ method was slower at low optimizations and faster at -O2 and above
for the testing done at the time I changed over.
(b) In povr, I'm using entry 43 for f_elliptical_sphrswp() and I will
have to move f_elliptical_sphrswp() elsewhere.
(c) Though, with hash based symbol/token tables with linked lists
hanging off each node, whether you see any a performance gain depends on
the particular symbol table construction. Having fewer symbols/tokens
will never hurt performance, but it can help quite a lot - depending on
'stuff.'
>
> ((real) minor nit, suggest 'fork', or perhaps even 'branch', rather than
> 'patch')
>
Good idea and I guess in the git sense, fork, the better choice because
in the usual practice there will often be branch(es) off major forks for
particular features of the fork. Any branches we should probably handle
as additional _str and _val entries.
>
>> Aside: I had the thought too for a patch_keyword("sky_sphere"). Which
>> might return say "unchanged". Or "emission sub keyword is now amplify"
>> or "removed" or "new" or "substantially updated see povr documentation"
>> or... I'm thinking more about code which self documents to some minimal
>> degree.
> 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?
On automatically including includes, I lean against it. How external
files get searched for and found is today problematic. I've been trying
to simplify the povr fork directory search mechanism. Still a long way
to go there and might have some current changes wrong. Official
POV-Ray's matching attempts are very aggressive in assuming various
directories, file suffixes and such. I think this causes as much
confusion as not in the end.
On versioning... Following some conventions there a good idea, but not
sure it's something to force as part of any f_odd, fork_*() additions.
For someone actually implementing a one off patch, it's meaningless. I
have to say too, as a long time user of such versioned tools, I've found
them not all that reliable - except in maybe the ZZZ minor update
category (small updates to still compile essentially static releases).
Some systems extend the versioning to components / modules / features of
the overall 'user tool' - some allowing the user to pick the version of
behavior for each module. This 'idea' somewhat attractive given the more
aggressive changes I'm pursuing with povr.
For example, I substantially re-wrote 'fog' a year or more ago. One of
the changes was making ground fog work more reliably - it basically,
doesn't function for most scenes in official releases. Last fall I ran
across an old scene that depended upon the particulars of the previous
method to do a sort of fog fade at a large distance. It was a use I
didn't foresee for 'ground fog', so I restored the old method as an
additional option. There are now two versions of my povr fog code.
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...
Bill P.
Post a reply to this message
|
|