Neither POV-Ray 3.7 nor UberPOV provides sufficient information when it fails to
execute the command line.  This has been a problem for YEARS with 3.7 beta.  On
2012 December 30, Thorsten Froehlich claimed that this was an oversight, but I
was extremely disappointed to find that it was not corrected in the final
release.

Once again, I have run across this situation, and once again, I spent an
unjustifiable amount of time busting my brains to figure out what I did wrong.

I am requesting that FS#41 be reopened.

POV-Ray versions: POV-Ray 3.7.0 and UberPOV 1.37.0.0-beta.4
Operating system: openSUSE 13.1 GNU/Linux
Hardware: Dell Inspiron 17R, Intel Core i7

Post a reply to this message

Le 02/02/2014 12:58, Cousin Ricky nous fit lire :
> Neither POV-Ray 3.7 nor UberPOV provides sufficient information when it fails to
> execute the command line.  This has been a problem for YEARS with 3.7 beta.  On
> 2012 December 30, Thorsten Froehlich claimed that this was an oversight, but I
> was extremely disappointed to find that it was not corrected in the final
> release.
> 
> Once again, I have run across this situation, and once again, I spent an
> unjustifiable amount of time busting my brains to figure out what I did wrong.
> 
> I am requesting that FS#41 be reopened.
> 
> POV-Ray versions: POV-Ray 3.7.0 and UberPOV 1.37.0.0-beta.4
> Operating system: openSUSE 13.1 GNU/Linux
> Hardware: Dell Inspiron 17R, Intel Core i7

Can we have a scene to reproduce ?
It does not seem to be in the SDL (as I got error reported with line and
expectation when I write a scene...), so any reproduction ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 02/02/2014 12:58, Cousin Ricky nous fit lire :
> > Neither POV-Ray 3.7 nor UberPOV provides sufficient information when it fails to
> > execute the command line.  This has been a problem for YEARS with 3.7 beta.  On
> > 2012 December 30, Thorsten Froehlich claimed that this was an oversight, but I
> > was extremely disappointed to find that it was not corrected in the final
> > release.
> >
> > Once again, I have run across this situation, and once again, I spent an
> > unjustifiable amount of time busting my brains to figure out what I did wrong.
> >
> > I am requesting that FS#41 be reopened.
> >
> > POV-Ray versions: POV-Ray 3.7.0 and UberPOV 1.37.0.0-beta.4
> > Operating system: openSUSE 13.1 GNU/Linux
> > Hardware: Dell Inspiron 17R, Intel Core i7
>
> Can we have a scene to reproduce ?
> It does not seem to be in the SDL (as I got error reported with line and
> expectation when I write a scene...), so any reproduction ?

It happens whenever you have an error on the command line.  It's a front end
problem.  It doesn't matter what's in the scene definition file.

In this case, it was a shell script with the line:

  uberpov Prism_lamps[post] +gld$GLD +oPrism_lamps-3gm2gld

I had edited the two-month-old script and accidentally deleted the command to
set the shell variable GLD.  The result was the the message:

  Problem with option setting
  uberpov Prism_lamps[post] +gld +oPrism_lamps-3gm2gld
  Failed to parse command-line option

The message gives absolutely no hint what the "problem" is.  As +gld a new
option that isn't quite burned into my brain, it took quite a while for me to
figure out that 1) the problem was with +gld and 2) there was a missing
argument.

Most commands that don't make it out of the front end (including something as
mysterious a having a .ini file that most certainly exists, because you are
staring straight at it, but you accidentally saved it to the wrong
directory--took me about 20 minutes to figure that one out) will result in the
same inadequate message.  Try this one:

  povray nexiste[pas]

Post a reply to this message

Dear Cousin Ricky,

Your happiness is easy to satisfy, with a bit of early advertisement:

--- a/vfe/unix/unixconsole.cpp
+++ b/vfe/unix/unixconsole.cpp
@@ -474,9 +474,11 @@ int main (int argc, char **argv)
                        opts.AddCommand (*argv);
        }

+       PrintStatus (session);
        // set all options and start rendering
        if (session->SetOptions(opts) != vfeNoError)
        {
+               PrintStatus (session);
                fprintf(stderr,"\nProblem with option setting\n");
                for(int loony=0;loony<argc_copy;loony++)
                {



The first PrintStatus dumps the classical page(s) about povray (from
version to Support libraries). (it's a bit earlier than currently, but I
do not find a reason to delay it to the parsing of the scene).

The second is used to dump the parsing error collected during the
examination of the command line options (and maybe more), in case of error.

Windows vfe (and mac too), might enjoy such changes too.

Post a reply to this message

Am 02.02.2014 20:28, schrieb Le_Forgeron:
> Dear Cousin Ricky,
>
> Your happiness is easy to satisfy, with a bit of early advertisement:
>
> --- a/vfe/unix/unixconsole.cpp
> +++ b/vfe/unix/unixconsole.cpp
> @@ -474,9 +474,11 @@ int main (int argc, char **argv)
>                          opts.AddCommand (*argv);
>          }
>
> +       PrintStatus (session);
>          // set all options and start rendering
>          if (session->SetOptions(opts) != vfeNoError)
>          {
> +               PrintStatus (session);
>                  fprintf(stderr,"\nProblem with option setting\n");
>                  for(int loony=0;loony<argc_copy;loony++)
>                  {
>
>
>
> The first PrintStatus dumps the classical page(s) about povray (from
> version to Support libraries). (it's a bit earlier than currently, but I
> do not find a reason to delay it to the parsing of the scene).
>
> The second is used to dump the parsing error collected during the
> examination of the command line options (and maybe more), in case of error.
>
> Windows vfe (and mac too), might enjoy such changes too.

That last sentence shows that we're doing something fundamentally wrong 
here: Ideally there should be only one piece of code to fix, for all 
POV-Ray front-ends.

This is probably also the reason for the confusion around FS#42: The 
command-line error reporting had already been made elaborate enough, but 
only in the Windows version.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 02.02.2014 20:28, schrieb Le_Forgeron:
> > [...]
> > Windows vfe (and mac too), might enjoy such changes too.
>
> That last sentence shows that we're doing something fundamentally wrong
> here: Ideally there should be only one piece of code to fix, for all
> POV-Ray front-ends.

But as the commentary at FS#42 shows, one piece of code may not be adequate for
/all/ situations.  (And I'd love to help, but I burned out before I learned
C++.)

> This is probably also the reason for the confusion around FS#42: The
> command-line error reporting had already been made elaborate enough, but
> only in the Windows version.

Do you mean FS#41 here?

Post a reply to this message

Am 04.02.2014 03:00, schrieb Cousin Ricky:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 02.02.2014 20:28, schrieb Le_Forgeron:
>>> [...]
>>> Windows vfe (and mac too), might enjoy such changes too.
>>
>> That last sentence shows that we're doing something fundamentally wrong
>> here: Ideally there should be only one piece of code to fix, for all
>> POV-Ray front-ends.
>
> But as the commentary at FS#42 shows, one piece of code may not be adequate for
> /all/ situations.

Well, the trick there must be to parse the command line in two stages:

(1) One stage to separate the command line into individual parameters 
and "canonicalize" their format; this code must be individual for each 
platform. (For instance, Unix already splits up the command line into 
individual parameters before passing those to the program, while Windows 
passes just one long command line string.)

(2) One stage to scan through the list of individual parameters and 
interpret them; this code should be the same for all platforms.


>> This is probably also the reason for the confusion around FS#42: The
>> command-line error reporting had already been made elaborate enough, but
>> only in the Windows version.
>
> Do you mean FS#41 here?

Yes, sorry.

Post a reply to this message