On 1/25/22 03:37, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 1/24/22 07:36, jr wrote:
>>> no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
>> ...
>> Grepping now I see amplify mentioned some in revisions_povr.txt and
>> pretty sure I added notes about it in a posting or two as well.
> 
> yeah, my memory..  :-(

Mine too. With changes like this I have a few places put in parser 
checks which generate more specific errors. For example, reflection now 
supporting only reflection blocks, but it's work and it happened in the 
reflection case mostly because the code was more or less there to do it 
even with a code comment it was the old form and that it was going away. 
It just wasn't generating an error yet though it looked like someone had 
set up to do it at some future point.

I'd like to make the differences easier to handle, but, it really comes 
to not knowing how to do it in the tiny amount of resource I have/want 
to spend on it.

I've been thinking about creating more documentation from the code base 
itself now that I understand it better, but not gotten to trying it.

> 
> 
>>> ..."#version unofficial 3.8;" ...
>>
>> Yeah, it's unfortunately a bit of mess since v3.7. One which clipka
>> tried variously to somewhat address.
>>
>> Writing from memory from earlier last year or late 2020... The
>> versioning stuff is something in an awkward state and I have no idea how
>> to really fix it.
>>
>> Ignoring that there was a more complex versioning proposal part of
>> uberpov, it was supposed to be we could write something like:
>>
>> #version unofficial povr 3.8;
>>
>> where the 'unofficial' keyword would STOP folks running a scene targeted
>> for some particular unofficial release in an official release of POV-Ray.
>>
>> I have no idea why unofficial is not itself documented. It's been there
>> a long time. Maybe because there was a worry folks would add it to
>> regular POV-Ray scenes or something... I think it should be documented.
> 
> if asked, and if written as above, I'd suggest introducing 'unofficial' as a new
> built-in variable which only exists if the keyword was used.  it could contain
> the id string, allowing something like:
> 
> #if (defined(global.unofficial))
>    #if (!strcmp(unofficial,"povr"))
>    ...
>    #end
> #else
>    ...
> #end
> 
> aside - 'povr' emits a warning when I use unofficial, the 'beta.2' simply
> ignores it :-).
> 

Something like that is a good idea. And thanks for reporting the warning 
only being there for povr. It looks like the current v4.0 master code 
has just:

#if POV_RAY_IS_OFFICIAL
         Get_Token();
         Error("This file was created for an unofficial version and\n"
               "cannot work as-is with this official version.");
#else
         // PATCH AUTHORS - you should not enable any extra features
         // unless the 'unofficial' keyword is set in the scene file.
#endif

in Parse_Version(...) where I have a warning in that #else. Maybe 
something I just did at some point? Or maybe I picked up something now 
gone in the official branches? I don't remember...

I just ran an old megapov scene in v3.7 and v3.8 beta1 (my beta 2 
testing was on my raspberry and I'm not on it at the moment). With both 
there parser dies with:

File 'area_light_refl.pov' line 16: Parse Error: Expected 'numeric
expression', undeclared identifier 'megapov' found instead...

which isn't as informative as it could be, but guess I like that the 
parsing dies up front on something that isn't going to work anyway.

I think that Get_Token() in the '...IS_OFFICIAL' branch might be to pick 
up tokens like 'mega_pov' or 'povr' and generate instead the error 
message. Maybe given the existing branches have empty warning branches I 
can just do want I want for povr in the else...

I'll look at your idea today and see if I can make something work for 
povr.

> 
>>>> ... the -win id thing ...
>>
>> Eh, I don't know. Pretty much all of the pfm rtr frame snap shot
>> capability and actual cycle control was done with a -win capability in
>> mind. The work just got dropped along with everything else.
> 
> have only used the snapshot setting a couple of times, to try.  found that
> 'convert' works just fine, no need for the "i version" ('file' too recognises
> them).
> 
> I am hoping that your (+ JG's) work on the X window handling, and the "-win
> thing" perhaps, will appear in POV-Ray proper (and before the heat-death of the
> universe, ideally :-)  is anyone working on 'beta.3'?).
> 

I'm not aware of any v3.8 beta work presently, but the github repository 
wasn't the only one. There exists some more private ones some of which I 
was aware, but I never knew much of anything about those. The developer 
mailing list has been quiet for a while - supposing I'm still connected 
to it and it's working. Some of the windows support always got done 
somewhere else as a dll I think, the documentation too. There is 
somewhere a repository or two for moray code where work seemed to start 
a few times, but then die out. There is active Blender interface work 
some of which is posted about here. All I know.

Bill P.

Post a reply to this message