Le 2024-03-26 à 13:39, Kenneth a écrit :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> I often stop POV-Ray after parsing by adding an #error directive:
>>
>> #error "Stopping after parse"
>>
>> at the very bottom of some scene description language (SDL) code.
>>
>> It works but, with the disadvantage of setting a non-zero return code;
>> something which makes testing the parser harder.
>>
> 
> What is a 'non-zero return code', and what testing problems(s) does it cause
> when using #error? I confess to complete ignorance of it :-/
> 
> 
> 

A zero return code is an universal way that a procedure use to indicate 
that it finished successfully. Any non-zero value indicate that there 
was some error occurring.

Post a reply to this message

Thanks guys. I learned something new!

Just out of curiosity: Where do these codes show up? Are they 'accessible' to a
typical (i.e. naive!) computer user in Windows?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Thanks guys. I learned something new!
>
> Just out of curiosity: Where do these codes show up? Are they 'accessible' to a
> typical (i.e. naive!) computer user in Windows?

I would guess that they're completely internal to source.
And once the code exits - the program is terminated.  So it's gone.

But that makes me think about the possibility of writing those values to a file,
or to some sort of shell environment variable.

Then you could parse a scene, exit without rendering, and do some post-parse
processing with a shell command....

Post a reply to this message

On 3/27/24 19:28, Kenneth wrote:
> Just out of curiosity: Where do these codes show up? Are they 'accessible' to a
> typical (i.e. naive!) computer user in Windows?

Most any place a compute working environment / locale has called a 
executable program, it's the normal to return, 'return codes'. In my 
Ubuntu Linux environment, the calling, work locale is my terminal where 
I type 'povray ...' to call the POV-Ray executable program.

I can look at the return code by looking at a special environment 
variable '?' which holds the return code of the command / program called 
/ run. The '$' prefix extracts the current integer value.

Supposing the file boom.pov contains a single line: #error "Boom",

	yuqk boom.pov
	echo $?

returns something like:

...
=== [Parsing...] ==================================================
File 'boom.pov' line 2:
Parse Error:
Parse halted by #error directive: Boom
Fatal error in parser: Cannot parse input.
Render failed

pokorny:tmp$ echo $?
1

I don't know the equivalent to 'echo $?' in a window's command terminal, 
but I'm sure there is one.

In testing, I'm using the new +wt0 trick and the return code value to 
create bash testing scripts like:

#!/bin/bash
#----------------------------------------------
# Herein running series of POV-Ray (yuqk) commands with good flag usage
# looking for any of them to fail.
#----------------------------------------------

export YUQK_PARSE_ONLY="yuqkA -d -p +wt0"

#---
if $YUQK_PARSE_ONLY version_only.pov >/dev/null 2>&1; then
     echo "Pass case: version_only.pov"
else
     RC=$?
     echo "Pass case: version_only.pov   FAIL  rc=$RC"
     exit $RC
fi

... 179 more tests of good flag usage follow


Bill P.


---
I was curious so played some more... It gets convoluted, please feel 
free to ignore the rest.


This also works in my yuqk fork, though I doubt whether it will work for 
official POV-Ray releases. Pretending the following is all on one line:
	
yuqk boom.pov fatal_error_command="echo \"Scene: <%s> 
fatal_error_command. RC: <$?>\""

It uses the fatal_error_command facility of POV-Ray itself. The output 
looks like:

==== [Parsing...] ==================================================
File 'boom.pov' line 2:
Parse Error:
Parse halted by #error directive: Boom
Fatal error in parser: Cannot parse input.
Scene: <boom> fatal_error_command. RC: <0>
Render failed

However! The return code (RC) reported by the 'fatal command' is not for 
the current running POV-Ray executable, but for the command previously 
run from the terminal, which is currently running the POV-Ray executable.

The following pile of a command shows how return code values exist in 
two locale environments here. The initial terminal and a second one the 
fatal error command sets up. Again imagine it all on one line:

ls;yuqk boom.pov fatal_error_command="yuqk boom.pov;RC=$?;echo \"boom 2 
RC=$RC\";echo \"Scene: <%s> fatal_error_command. RC: <$RC> and <$?> for 
initial 'ls'\"";

The output is:

...
File 'boom.pov' line 2:
Parse Error:
Parse halted by #error directive: Boom
Fatal error in parser: Cannot parse input.
Render failed

boom 2 RC=1
Scene: <boom> fatal_error_command. RC: <1> and <0> for initial 'ls'
Render failed


Yepper. The fatal error command is running yuqk with boom.pov a second 
time just to capture the eventual return code - which the first running 
version of yuqk has not yet set itself... :-)

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> This also works in my yuqk fork, though I doubt whether it will work for
> official POV-Ray releases. Pretending the following is all on one line:
>
> yuqk boom.pov fatal_error_command="echo \"Scene: <%s>
> fatal_error_command. RC: <$?>\""
>
> It uses the fatal_error_command facility of POV-Ray itself. The output
> looks like:
>
> ==== [Parsing...] ==================================================
> File 'boom.pov' line 2:
> Parse Error:
> Parse halted by #error directive: Boom
> Fatal error in parser: Cannot parse input.
> Scene: <boom> fatal_error_command. RC: <0>
> Render failed
>
> However! The return code (RC) reported by the 'fatal command' is not for
> the current running POV-Ray executable, but for the command previously
> run from the terminal, which is currently running the POV-Ray executable.

can you use BE's "to file" idea ?  ie write the exit / status code as last line
when 'all_file=true', perhaps.


regards, jr.

Post a reply to this message

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