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

On 2/17/22 02:39, jr wrote:
> chain-loading via 'file_exists()' is nice + "clean" (imo).
> 

I'm not completely sure I'm following what you mean by chain-loading?

I've adopted the use of file_exists() on deciding to ship a version.inc 
with povr. The overall implementation is done in a 
scene->version.inc->forkversion.inc way. Is this what you mean by 
chain-loading?

---
file_exist() is one of those things which is clean until it's not. :-)

Think about how we've often shipped binaries intended to run on a 
earlier install base. There is build infrastructure to support this 
model of update. A model somewhat workable because official POV-Ray 
supports backward compatibility. It's problematic in that to safely 
align with any given binary you need the binary's includes too - 
something that in POV-Ray proper requires a full install.

Think too about how the search path is user modifiable.

Anyhow, it's the method we have. I agree too for normal users with a 
single installation of POV-Ray, and relatively constant include files, 
file_exist is safe enough.

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

Practically, I don't think I've got the bandwidth for anything 
revolutionary in the povr fork.

It would probably be TCL if I do get around to trying something radical. 
I have a lot of that going today - as you know - but the implementation 
writes SDL. In other words, it still leans on the current SDL parsers.

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

My up front answer - difficult. The parser is still too integrated with 
the run time code. As something part of my povr branch it's not the most 
unattractive idea because it tangles me in two different parser 
implementations.

Aside: I've thought about hacking versions of POV-Ray in a way where 
they could be run as 'parse to some intermediate form and stop' 
utilities. And that thought reminds me I want to implement an actual 
#stop after parse directive. I use #error, but it's an ugly way to stop 
after the parsing stage.

Anyway, thanks for the ideas! As with the ini and options setting 
approaches, I'm still uncertain where the povr code will go.

> 
> have only spent a few minutes looking over the attached, seem ok (bar copy/paste
> typos 'str_var' in 'forkversion.inc'.)

Thanks. I believe that fixed.

And apologies. I must not of finished the editing of forkversion.inc (or 
somehow didn't do a last save...) I picked up a number of other mistakes 
'I thought' I'd fixed.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/17/22 02:39, jr wrote:
> > chain-loading via 'file_exists()' is nice + "clean" (imo).
> >
>
> I'm not completely sure I'm following what you mean by chain-loading?

do file_exists (filename)
if yes, run/include that file.
In THAT file is _another_ file_exists (filename)... and so on

daisy-chain everything together until you hit a dead-end.



> Aside: I've thought about hacking versions of POV-Ray in a way where
> they could be run as 'parse to some intermediate form and stop'
> utilities. And that thought reminds me I want to implement an actual
> #stop after parse directive. I use #error, but it's an ugly way to stop
> after the parsing stage.

Yes.
More useful would be to have that as a "function" that returns some sort of
state variable, visible to the OS/shell

I've also thought about a mechanism to "stop" and then _reparse_ the SDL file,
such that certain things could be scanned, written to file, or otherwise do a
pre-parse-and-render setup.  Maybe something like: #reparse 3
POV-Ray would parse until it hit that, decrement a counter, etc, until it read
through that directive at counter = 0.

I suppose we have workarounds for stuff like this.

I've also wondered about write-protecting files in some way to make editing them
a conscious and fully purposeful action.   Like locking the cells in a
spreadsheet so that critical, complicated formulas don't get edited by someone
trying to "improve" things.  ;)

Silly idea:   certain image formats have header sections where you can embed
virtually anything.   Would it be possible to have POV-Ray store scene files in
an image file format, with the SDL embedded in the header?  Not sure where I was
going with this a second ago - but just thinking about such a thing might spark
some new ideas about structuring scene, includes, etc.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/17/22 02:39, jr wrote:
> > chain-loading via 'file_exists()' is nice + "clean" (imo).
> >
>
> I'm not completely sure I'm following what you mean by chain-loading?

as BE says.  what I tried to say is something like the mechanism is nice/clean
because it all is/can be transparent to the user (as your code snippet
demonstrates).


> > > Thinking
> ...
> It would probably be TCL if I do get around to trying something radical.

please do!  ;-)


> I have a lot of that going today - as you know - but the implementation
> writes SDL. In other words, it still leans on the current SDL parsers.

I guess that a C(++) extension for Tcl, to drive the VM from Tcl, would do it
:-), access through some "specialising" packages/modules perhaps.


> > 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)
>
> My up front answer - difficult. The parser is still too integrated with
> the run time code. As something part of my povr branch it's not the most
> unattractive idea because it tangles me in two different parser
> implementations.

ah, naively I'd thought that the existing CLI/ini 'version' could be (ab)used,
ie if not given start with forked parser, if any file read needs <3.8 stop/error
tell user either needs option switch (to start with the "compatible") or edit
offending file.


> Aside: I've thought about hacking versions of POV-Ray in a way where
> they could be run as 'parse to some intermediate form and stop'
> utilities. And that thought reminds me I want to implement an actual
> #stop after parse directive. I use #error, but it's an ugly way to stop
> after the parsing stage.

agree with BE, being able to return a status from a scene would be neat,
particularly if it's available for 'post_frame_command's.

also re his "silly idea", SDL (and or pre-parsed VM calls) storage -- how about
DB (sqlite) storage?


> Anyway, thanks for the ideas! As with the ini and options setting
> approaches, I'm still uncertain where the povr code will go.

:-)  you'll have to tell me when to stop.


regards, jr.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Silly idea:   certain image formats have header sections where you can embed
> virtually anything.   Would it be possible to have POV-Ray store scene files in
> an image file format, with the SDL embedded in the header?  Not sure where I was
> going with this a second ago - but just thinking about such a thing might spark
> some new ideas about structuring scene, includes, etc.

look at attached with:

  $ hexdump -C hu_8.png | less

that what you mean?  ;-)

anyway, long story short, you can do in Tcl, for .png files.  install the
'Tcllib' package, then check out the man page (section n on my box) for 'png'.


regards, jr.

Post a reply to this message

Attachments:
Download 'hu_8.png' (17 KB)

Preview of image 'hu_8.png'

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > Silly idea:   certain image formats have header sections where you can embed
> > virtually anything.   Would it be possible to have POV-Ray store scene files in
> > an image file format, with the SDL embedded in the header?  Not sure where I was
> > going with this a second ago - but just thinking about such a thing might spark
> > some new ideas about structuring scene, includes, etc.
>
> look at attached with:
>
>   $ hexdump -C hu_8.png | less

Well, not exactly.   I think I wrote that on my way out to work, so it was just
a short brain-dump.

What I was actually thinking was that POV-Ray could use an image format as the
actual file format for storing the SDL text, and the editor could extract it
from that, display it, allow for editing, and re-save into the image file
wrapper.

Why do this:
I guess the idea was that since POV-Ray already has the ability to
parse/interpret image file formats already, it might be possible to somehow
embed a series of text files into the image header - like includes, etc and use
it kind of like a zip file.

Also, then we could have the image and the code that generated it all in one
place, so they aren't separated and lost/confused.

It might also be possible to implement security by obscurity, to protect certain
parts of code that an author might not want users casually messing with.  If you
really wanted to edit that code, you'd have to work for it, rather than just
"Ooops!  I broke it!"

But binary copy, hexdump, Tcp, and other tools might provide a sort of
functional work-around / proof of concept to see how a suite of files could
potentially be used ....

Post a reply to this message

On 2/28/22 06:47, jr wrote:
> look at attached with:
> 
>    $ hexdump -C hu_8.png | less
> 
> that what you mean?;-)
> 
> anyway, long story short, you can do in Tcl, for .png files.  install the
> 'Tcllib' package, then check out the man page (section n on my box) for 'png'.

Neat.

What particular commands and versions of TCL and Tcllib are you using?

It's been maybe 4-5 years since I played in the tcl/png sandbox but, not 
too long after tcl 8.6 was first released, I found the png support from 
within tcl/tk/tcllib buggy. Supposing you are finding it better?

I was primarily trying to load/create/modify/save actual image channel 
data but, I don't recall even the particular 'TCL' packages and commands 
I tried at the moment...

Bill P.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> What I was actually thinking was that POV-Ray could use an image format as the
> actual file format for storing the SDL text, and the editor could extract it
> from that, display it, allow for editing, and re-save into the image file
> wrapper.
>
> Why do this:
> I guess the idea was that since POV-Ray already has the ability to
> parse/interpret image file formats already, it might be possible to somehow
> embed a series of text files into the image header - like includes, etc and use
> it kind of like a zip file.
>
> Also, then we could have the image and the code that generated it all in one
> place, so they aren't separated and lost/confused.

- keeping "image and the code" in one place, along with the includes, bg
image(s) etc, would be ideal.  a project oriented approach.  and zip would be a
good format.

- hate the idea/concept of "allow for editing, and re-save into the image file
wrapper".  if anything the other way round, keep everything plain human-readable
text and include image(s) and other binary content 'base64' encoded.

anyway, thanks, have a clearer picture now of the "silly idea".


> It might also be possible to implement security by obscurity, to protect certain
> parts of code that an author might not want users casually messing with.  If you
> really wanted to edit that code, you'd have to work for it, rather than just
> "Ooops!  I broke it!"

also not keen on this.  if an author feels .. so strongly, well, then don't
publish.  simples.


> But binary copy, hexdump, Tcp, and other tools might provide a sort of
> functional work-around / proof of concept to see how a suite of files could
> potentially be used ....

why binary anyway?  what's wrong with a plain text (or utf8) encoding?


regards, jr.

Post a reply to this message