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.

I've a few times talked about adding a new (SDL) directive like '#exit 
<rc value>', perhaps.

Well, while continuing to work through the ini options and command line 
flags, I stumbled across the following trick. We can effectively run 
just the command line, ini file and scene file parsing with the command:

   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.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>[...]
>    povray scene.pov -d -p +wt0
>
>[...], 0 return code - [...]

Ah nice, I always used -d +w0 +h0 -F, but then you get a render failed.

ingo

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> I often stop POV-Ray after parsing by adding an #error directive:
> ...

v nice, and thank you.  I now have a "cleaner" 'povparse' alias.


regards, jr.

Post a reply to this message

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 :-/

Post a reply to this message

On 3/26/24 13:39, Kenneth wrote:
> 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 :-/
Hi.

Programs - like POV-Ray - running within typical compute environments, 
return a final integer value called a return code indicating how 
'things' went.

With POV-Ray it's mostly:

0 - All is well.
1 - Some lessor user-ish exit or abort.
2 - Some more serious problem.

But, you can see other non-zero codes too. This more true in yuqk - 
especially the debug compile.


An #error directive will cause POV-Ray to always return (1). Any testing 
looking for "0 - All is well" (or !0), will always see a problem (or 
not) if looking at just the return code(*) where '#error' the technique 
stopping POV-Ray at the parsing stage.

With yuqk, close the X11 preview window with 'q' while the render is in 
progress and you see a return code of (2).

With yuqk, close the X11 preview window, once the render is finished and 
paused, using the 'x' symbol to close and you see a return code of 
(139). Yes, that's a minor bug.

(*) - You can still check how things ran, but without the return code 
giving you the easy answer up front, it means looking at various outputs 
in some detail and checking whether what you expect to be there is, or 
isn't.

Bill P.

Post a reply to this message

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