POV-Ray : Newsgroups : povray.binaries.images : A quick povr branch micro normal image. : Re: A quick povr branch micro normal image. Server Time
24 Apr 2024 02:14:09 EDT (-0400)
  Re: A quick povr branch micro normal image.  
From: jr
Date: 27 Jan 2022 11:00:00
Message: <web.61f2c023c1365d06ea8869266cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Instead of using f_odd() to return additional patch/branch information,
> I think it should instead return always a value f_odd() cannot. For
> example, 99.0(a).
>
> The 99 indicates the code contains a patch or is a significant branch of
> its own. Further, that two additional parse time functions exist in:
>
> patch_str(<n>) and patch_val(<n>)
>
> With this approach we use f_odd() as a hook into all versions of POV-Ray
> back through v3.5(c) to indicate the two patch_* keywords exist.
>
> What each branch/patch provider does with those is up to them both to
> implement and document to their users.
>
> Allowing any number of strings and values would allow documenting
> particular functionality and the version of that functionality ->
> "amplify" 0.003.
>
> Is this a better approach(b) than f_odd alone?
>
> It's gets us away from any dependency POV-Ray's official development.

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?

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.  :-)

((real) minor nit, suggest 'fork', or perhaps even 'branch', rather than
'patch')


> 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.  :-)


regards, jr.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.