On 3/29/24 13:08, jr wrote:
> can you use BE's "to file" idea ?  ie write the exit / status code as last line
> when 'all_file=true', perhaps.

I think not reliably from within POV-Ray itself(a).

Some events, like segmentation faults, are being generated by libraries 
in use by POV-Ray and they are, more or less, crashing the program in a 
way the operating system ends up handling.

(a) - The 0, 1, 2 return codes are ones handled by POV-Ray itself and 
these could be written to stderr / cerr prior to exit, but not to one of 
the output streams as defined and handled by POV-Ray.

In Unix environments we can today do this:

yuqk boom.pov;echo "yuqk return code is: $?";

or

povray boom.pov;echo "povray return code is: $?";

or

povray boom.pov;export POVRAY_RC=$?;

'yuqk' is really a wrapper script around the yuqk fork's 'povray' 
executable where the last line is 'exit $?' to pass the return code back 
to the calling process. That wrapper could be modified to output to 
always write out a status line with the return code to the terminal - or 
to a file.

The yuqk fork has a getenv() function so you could run another SDL .pov 
file which does something with a YUQK_RC environment variable.

unset YUQK_RC;yuqk boom.pov;export YUQK_RC=$?;yuqk getenv.pov -d -p;

Where getenv.pov contains:

#debug concat("The return code is: ",getenv("YUQK_RC"),"\n")

and then the second yuqk will print: "The return code is: 1".

Rather than a #debug statement, that could be a #write I guess doing 
more stuff based on the value.

I don't know how to handle self generated return codes with only one 
call to the 'povray' executable.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/29/24 13:08, jr wrote:
> > can you use BE's "to file" idea ?  ie write the exit / status code as last line
> > when 'all_file=true', perhaps.
>
> I think not reliably from within POV-Ray itself(a).
>
> Some events, like segmentation faults, are being generated by libraries
> in use by POV-Ray and they are, more or less, crashing the program in a
> way the operating system ends up handling.
>
> (a) - The 0, 1, 2 return codes are ones handled by POV-Ray itself and
> these could be written to stderr / cerr prior to exit, but not to one of
> the output streams as defined and handled by POV-Ray.

was / am thinking documentation.  it would have been handy to read (at the end
of 'alltext.out') whether there were warnings and or (non-library) errors.


> ...
> The yuqk fork has a getenv() function ...

interesting.  what use case do you have in mind ?  (un)set in-scene "flags" ?


> I don't know how to handle self generated return codes with only one
> call to the 'povray' executable.

not sure I understand, the "(a)" above would do though, aiui.


regards, jr.

Post a reply to this message

On 3/31/24 07:32, jr wrote:
> was / am thinking documentation.  it would have been handy to read (at the end
> of 'alltext.out') whether there were warnings and or (non-library) errors.
> 

Short on time this morning. First, remember alltext.out (all_file) is 
just echoing the five other actual console streams to a single file.

The set up was >5 output streams, down to five today. In those five 
there is a warning stream and a fatal / error stream. Those latter two 
do capture all the warnings and errors to files if you set up your run 
that way. Those two files will be empty if all is well and otherwise 
have all the warnings and errors captured by POV-Ray.

We don't count warnings today which is an interesting idea.

> 
>> ...
>> The yuqk fork has a getenv() function ...
> interesting.  what use case do you have in mind ?  (un)set in-scene "flags" ?
> 

Nothing too specific. One thought was to enable POV-Ray to query the 
process environment from which it was called. USER, USERNAME, LANG, 
HOME, ...

I think you are suggesting SDL capability to set and unset environment 
variables too?  If so, I thought about. It is, though, a capability 
which could cause quite a bit of trouble.

> 
>> I don't know how to handle self generated return codes with only one
>> call to the 'povray' executable.
> not sure I understand, the "(a)" above would do though, aiui.

I can look at doing (a). What I do not know at the moment is where 
stdout / stderr are go as compared to where +o- image output goes. I 
suspect, the optional image output is using stdout so I could use stderr 
for the 0, 1 or 2 return codes. If so, zero return code result messages 
would end up on stderr which is a little off.

Anyhow, got to run.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
>   povray scene.pov -d -p +wt0
>
> Setting the thread count to zero causes POV-Ray to bail before rendering
> with a clean, 0 return code - so long as nothing is otherwise wrong with
> the scene set up.
>
> It means I've got a better way to run parsing test cases and, should
> anyone want to do it, you can use SDL as a sort of scripting language to
> do other stuff.
>
> The trick works too in v3.8 beta 2 and likely all recent, official
> versions.
>
> Bill P.

-d -p +wt0 works on my win3.7 version just put it in the command box and run
Great Trick!

Post a reply to this message

On 4/15/24 13:26, Leroy wrote:
> Great Trick!

Hi Leroy,

I'm glad I stumbled across it. Now that I've got this easier way to test 
ini files and command line flags, I'm finding quite a bit of stuff in 
need of fixing!

Bill P.

Post a reply to this message