"jr" <cre### [at] gmailcom> wrote:

> that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
> impossible.

I don't know what that does, and that may be true with the current way
everything functions.

If WP is going to change things, then I see no reason why something like
CLI_settings {all your CLI / ini stuff}
couldn't serve the same purpose.
And THAT could have the same ifndef functionality where things already declared
outside of the file - in CLI or ini - would preclude redefinition in the
CLI_settings {} block.

> personally, I frequently benefit from that flexibility.

Not using that method of running POV-Ray, I'd need to see a specific use example
where a separate file would be necessary.  Like I said - maybe not necessarily
get rid of it, but complement it with an in-SDL method to accomplish the same
thing.

If there was a way that POV-Ray could read from inside of an uncompressed
archive file, then we could tie interconnected files together so as to not
inadvertently separate them, yet still be able to read/edit them.
Apparently tar does this.

https://stackoverflow.com/questions/9516365/create-a-zip-archive-without-compression
https://stackoverflow.com/questions/430973/create-zip-style-file-without-compression

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
> > impossible.
>
> I don't know what that does, and that may be true with the current way
> everything functions.

say you have a number of .. knobs which change things in a scene, like having
radiosity enabled or disabled, eg
  #if (1 = Rad)
    // the radiosity stuff.
  #end

then, either on the command-line or in an .ini, you could
  declare=Rad=1
to enable radiosity for (just) that render, w/out needing to edit the scene.

can't have strings, ie 'declare=X="foo"' won't work, still, v useful.

> ...
> If there was a way that POV-Ray could read from inside of an uncompressed
> archive file, then we could tie interconnected files together so as to not
> inadvertently separate them, yet still be able to read/edit them.
> Apparently tar does this.

+1.  bundling up all project scene/inc/image/etc files in a single container,
and POV-Ray "mounting" them as virtual file systems, would be extremely neat.
(one for version 5.x.  :-))


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ....
> Dump the inbuilt benchmark. ...

popped into my head this morning.  :-)  occurs to me that not only is having
this benchmark "nice", even if only for own information, it is also, in a sense,
a convenient and built-in 'make check' equivalent.  so I think that unless
there's an explicit 'make check' which exercises the build, the '--benchmark'
(too) ought to be kept.


regards, jr.

Post a reply to this message

On 6/21/20 5:14 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ....
>> Dump the inbuilt benchmark. ...
> 
> popped into my head this morning.  :-)  occurs to me that not only is having
> this benchmark "nice", even if only for own information, it is also, in a sense,
> a convenient and built-in 'make check' equivalent.  so I think that unless
> there's an explicit 'make check' which exercises the build, the '--benchmark'
> (too) ought to be kept.
> 

There is today an explicit 'make check' which uses the advanced 
directory biscuit scene(1). I'm thinking about changing 'make check' to 
something much simpler like a sphere on a checkered plane. I don't think 
there is any reason for a more complete scene for the 'make check' 
functionality.

(1) - Running in a mangled way for my povr compiles at present.

The current inbuilt benchmark amounts to wrappers around the scene 
directory benchmark scene and ini files. Plus, it looks to me, 4 font 
files which exist in the include directory get wrapped too. These are 
the inbuilt fonts text{} can use. I think the whole idea is to let the 
benchmark types at whatever news publication run the benchmark without 
an actual install. The wrapped/c++ encapsulated stuff gets written out 
to files for the --benchmark. Not sure where written at the moment. I've 
looked at little at the encapsulation side, but not how it actually runs.

In any case, as done it amounts to a significant duplication of files. 
Nothing really against it, other than it being something more which must 
be maintained and that it takes around 700K (6.5% of povr today) of 
source code space.

Aside: The current benchmark scene could be made more representative - 
or perhaps their should be several benchmarks. Last I profiled the 
benchmark was, time wise, 65% or more noise(NG 1) and media.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/21/20 5:14 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ....
> >> Dump the inbuilt benchmark. ...
> >
> > popped into my head this morning.  :-)  occurs to me that not only is having
> > this benchmark "nice", even if only for own information, it is also, in a sense,
> > a convenient and built-in 'make check' equivalent.  so I think that unless
> > there's an explicit 'make check' which exercises the build, the '--benchmark'
> > (too) ought to be kept.
>
> There is today an explicit 'make check' which uses the advanced
> directory biscuit scene(1). I'm thinking about changing 'make check' to
> something much simpler like a sphere on a checkered plane. I don't think
> there is any reason for a more complete scene for the 'make check'
> functionality.

see below.

> The current inbuilt benchmark ... Not sure where written at the moment. ...

/tmp/

> ...
> Aside: The current benchmark scene could be made more representative -
> or perhaps their should be several benchmarks. Last I profiled the
> benchmark was, time wise, 65% or more noise(NG 1) and media.

agree, as long as this, and or the 'make check', utilise a good cross-section of
the functionality, they should that and no more.


regards, jr.

Post a reply to this message