Bug: When using the #error directive the string is not printed.

From the POV-Ray documentation:

--------------------
6.2.7.1  Text Message Streams
The syntax for a text message is any of the following:

TEXT_STREAM_DIRECTIVE:
    #debug STRING | #error STRING | #warning STRING

Where STRING is any valid string of text including string identifiers or
functions which return strings.
--------------------

But when running the following scene:

--------------------
#declare String = "B must be a positive number!"

#error String
--------------------

POV-Ray prints the following to the message pane:

--------------------
File: C:\Programmer\POV-scenes\#Mine\35tests\Errorbug.pov  Line: 5


#error String <----ERROR

Parse Error: User error directive hit.


Returned from renderer with error status
--------------------

IIRC this has been the behavior in any version of POV-Ray I know of.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bd1515e$1@news.povray.org> , "Rune" 
<run### [at] mobilixnetdk> wrote:

> Bug: When using the #error directive the string is not printed.

This is a documentation problem IMO.  As the error is "caused" by the user
POV-Ray should really not print it out because this would make it look like
_POV-Ray_ generated the error, which is not true.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> This is a documentation problem IMO.  As the error is
> "caused" by the user POV-Ray should really not print it
> out because this would make it look like _POV-Ray_
> generated the error, which is not true.

What???

So does it also look like POV-Ray is making all #debug and #warning
messages?

I don't get your reasoning. Please tell me again why creators of include
files should not have the ability to output an instructive error message to
the user. The pane can still say "Parse Error: User error directive hit."
but it should also print the string so the user can know what the error is.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3bd16402@news.povray.org...
> "Thorsten Froehlich" wrote:
> > This is a documentation problem IMO.  As the error is
> > "caused" by the user POV-Ray should really not print it
> > out because this would make it look like _POV-Ray_
> > generated the error, which is not true.
>
> What???
>
> So does it also look like POV-Ray is making all #debug and #warning
> messages?
>
> I don't get your reasoning. Please tell me again why creators of include
> files should not have the ability to output an instructive error message to
> the user. The pane can still say "Parse Error: User error directive hit."
> but it should also print the string so the user can know what the error is.
>

I concur.  For a while I was writing #warning messages followed by #error to
stop the parse.  But that means two lines of code where one should suffice.

IMO, if #error doesn't print the string it's passed, it shouldn't require a
string.  So, either the requirement should be used or the string should be
printed after being parsed.

BTW, if you omit the string, the following error occurs:
File: C:\My Documents\POVRay\Test\error.pov  Line: 1
#error

 <----ERROR

Parse Error: Expected 'string expression', End of File found instead


Returned from renderer with error status

Michael

Post a reply to this message

In article <3bd16402@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> I don't get your reasoning. Please tell me again why creators of include
> files should not have the ability to output an instructive error message to
> the user.

Because the error messages tend to be assumed to come from POV-Ray most of
the time.  This is even true for warnings, but as those don't stop POV-Ray
people who don't understand the difference will just wonder but hardly ever
complain.  With an error message on the other hand, especially one that
cannot be found in the scene file it is far less likely people will
understand why they got an error because POV-Ray is pointing at one place
but showing a completely different message.

Let me give you an example question I expect to show up in p.newusers within
a few weeks after the error output would have been changed:

>>
Help!  POV-Ray doesn't like my aspect ratio whatever that is!  It says
"Parse Error: User error directive hit. Your aspect ratio will not work with
this scene!"  What am i doing wrong?
<<

I know, I know, I should not make such assumptions and because #error
directives are rare we might not see many of these problems reported, but I
am sure that we will see 50% of *all* #error problems being reported while
we might only see 0.1% of all #warning directive problems being reported
simply because a warning is something a user can ignore but an error he/she
has to deal with!


    Thorsten

Post a reply to this message

In article <3bd17e84@news.povray.org> , "Redbeard \(MDJohnson\)" 
<red### [at] wvadelphianet> wrote:

> IMO, if #error doesn't print the string it's passed, it shouldn't require a
> string.

An #error should not allow a string, but enforce a quoted "something".  This
is necessary so one at least has a chance to find out what the #error is
about without having to read the whole scene file.

    Thorsten

Post a reply to this message

"Thorsten Froehlich" wrote:
> "Redbeard (MDJohnson)" wrote:
>
> > IMO, if #error doesn't print the string it's passed,
> > it shouldn't require a string.
>
> An #error should not allow a string,

But it requires a string. That must be a bug then?

> but enforce a quoted "something".

A quoted "something" that is not a string? How do you define this in clear
terms?

> This is necessary so one at least has a chance to find
> out what the #error is about without having to read the
> whole scene file.

Perhaps the word you're looking for is "comment". However, comments have a
different syntax which is // or /* */

As it is now there's clearly something wrong as the directive requires a
string but doesn't use it for anything.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bd18f62@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>> An #error should not allow a string,
>
> But it requires a string. That must be a bug then?
>
>> but enforce a quoted "something".
>
> A quoted "something" that is not a string? How do you define this in clear
> terms?

There are two different definitions of "string" we are talking about.  The
firs one is what POV-Ray allows as a function that defines a string, which
in the POV-Ray parser syntax is simply called "STRING".  The second
definition, which I called "quoted something" is simply anything that may
appear between two quotes, but no functions or other tokens.

To show it by example, the following should be legal:

#error "My message"
#error ""
#error "abc"

While these should be illegal:

#error foo
#error this is the error message
#error

The reasoning behind this being a) that the error message is easier to find
in the complex POV-Ray syntax because it gets colored in the most common
editors used to edit pov files and b) that it is easy to find the end of the
error message simply by looking for the second quote so POV-Ray can gibe the
error location at the end of the #error line.

I should note that b) is also the reason why it currently takes a string -
this way the error will point to the end of the #error directive message
rather than the beginning.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

And I repeat:

POV-Ray *does* allow a pre-defined string to be used. You said that it
shouldn't allow a pre-defined string to be used*. So that must be a bug?

* quote from Thorsten:

"An #error should not allow a string, but enforce a quoted "something"."

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bd1c193@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> So that must be a bug?

No, because the documentation never says that the #error string is printed
to the #error stream and the documentation matches what POV-Ray does.  Of
course this does not mean it is the best way to do it or that this
particular part of the documentation is perfect, but an incomplete
specification isn't a bug.  Oh, and note that the error message is actually
displayed once already in the line showing with the #error directive...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> "Rune" wrote:
>
> > So that must be a bug?
>
> No, because the documentation never says that the
> #error string is printed to the #error stream

Yes it does.

"There are seven distinct text streams that POV-Ray uses for output. You may
output only to three of them."

Look, no matter how you put it there is a bug*, and not just in the
documentation.

If the error directive is supposed to only accept quoted text, but not
pre-defined strings, then there's a bug because it does accept pre-defined
strings.

If the error directive is supposed to accept any string, including
pre-defined strings, then there's a bug because the string is not used for
anything at all, and thus the user don't see the string.

> Oh, and note that the error message is actually displayed
> once already in the line showing with the #error directive...

Not if the error message is a pre-defined string.

* Of course I don't have the final saying in this, but I haven't yet seen
any arguments that indicate otherwise.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bd21d93@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>> No, because the documentation never says that the
>> #error string is printed to the #error stream
>
> Yes it does.
>
> "There are seven distinct text streams that POV-Ray uses for output. You may
> output only to three of them."

You generate output to the error stream in form of the line quoted by the
"<-- Error" message which dumps the line with the error message.  And note
that the documentation says nothing about actually outputting the string
behind the error message.  In fact after reading it several times I get the
impression the documentation is doing more than just explain the use of text
streams.  It also tells you what those text streams are and that you get a
parse error when using the #error directive.  It never says there can't be a
render time output with these directives, which of course is nonsense.

> If the error directive is supposed to only accept quoted text, but not
> pre-defined strings, then there's a bug because it does accept pre-defined
> strings.

No, because the documentation and the behavior of POV-Ray match in all clear
areas of the documentation.  As the documentation is not clear what happens
with the output, it is up to the user interpretation.

I do agree with you that the situation needs to be improved.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

About this discussion about the #error directive:

  Also I think that POV-Ray should print the string given to #error.

  Suppose that you have a macro like this, which takes a parameter which
should be a float value which is >=0 and <1:

#macro FancyMacro(Value)
  #if(Value<0 | Value>=1)
    #error concat("In FancyMacro(): Given parameter value ",
                  str(Value,0,-1),
                  " is out of range.\n")
  #end
  
  // Do something fancy here
#end

  And now suppose that you make a slight mistake when calling it:

#declare Ind = 0;
#while(Ind <= 10)
  FancyMacro(Ind/10)
  #declare Ind = Ind+1;
#end

  Now, which error message is clearer, the one POV-Ray currently gives:


File: C:\somepath\somefile.pov  Line: 5
                  str(Value,0,-1),

                  " is out of range.\n") <----ERROR

Parse Error: User error directive hit.


or what POV-Ray *should* print:


File: C:\somepath\somefile.pov  Line: 5

In FancyMacro(): Given parameter value 1 is out of range.

Parse Error: User error directive hit.


  And this does not look like an error message given by POV-Ray itself.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3bd28879@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   And this does not look like an error message given by POV-Ray itself.

To whom?  The 1% of very advanced users who know each and every error
message POV-Ray can generate?


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Some OS, like VMS, prepend a string to the error that indicates
the application that emits the error, its severity, and a short
error code so that users can look into the index of the manuals.
The remainder of the line is occupied by the actual error message.

POV-Ray could also do that on a very much limited scope. You
could add [POV error] and [POV warning] at the beginning of errors
generated by POV-Ray and [Scripted error] and [Scripted warning]
at the beginning of lines generated by directives. Granted, this
is a bit too verbose, but you get the idea.

You'd still have people who would come complain wrongly, but hey,
they don't even read any error messages, so you could as well
output random error messages for them.

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

"Thorsten Froehlich" wrote:
> And note that the documentation says nothing about actually
> outputting the string behind the error message.

That's complete nonsense. From the documentation:

"There are seven distinct text streams that POV-Ray uses for output. You may
output only to three of them."

One of those is the #error stream. So the documentation does say that
POV-Ray outputs the string after the #error directive.

Here's some more from the documentation:

"The syntax for a text message is any of the following:

TEXT_STREAM_DIRECTIVE:
    #debug STRING | #error STRING | #warning STRING

Where STRING is any valid string of text including string identifiers or
functions which return strings."

So once and for all, it's clear that the #error stream is supposed to take
any string, including string identifiers or functions which return strings.

But it doesn't. That's a bug!

> You generate output to the error stream in form of the
> line quoted by the "<-- Error" message which dumps the
> line with the error message.

Right now that's the behavior, but that's clearly not the way it's supposed
to behave. It doesn't take string identifiers or functions which return
strings. It's a bug I tell you! What does it take to convince you???

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Warp" wrote:
> Also I think that POV-Ray should print the string given to #error.

<snipped example>

I completely agree! But what can mere POV-Ray users do to convince a
POV-Team member?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: To whom?  The 1% of very advanced users who know each and every error
: message POV-Ray can generate?

  Don't tell me that the current behaviour is better. With the current
behaviour you *can't* give reasonable error messages: you can't include
numerical values in the error message, you can't split the error message
into several lines, you can't generate the error message for example by
concatenating strings... Instead of seeing an error message, the user sees
a bunch of POV-Ray SDL code. What good does that do? It also makes the life
of the author of the code harder: If the same error message may happen in
more than one place, he can't use just a string identifier to avoid uselessly
repeating the same string several times.
  In fact, the current behaviour can be even more confusing: As seen in the
example, the user doesn't even see the "#error" keyword if the original code
is split into several lines. Thus the user may not know that it was an #error
command which caused the problem but could think that it is something else.

  If it's such a big deal that the user MUST NOT in any circumstance think
that the error message was generated by POV-Ray itself, then make it clear
by adding something to the messages around the error message string itself,
but allow the maker of the include file to be able to print proper error
messages and not just POV-Ray SDL code to the user. The SDL code doesn't
help the user.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Thorsten Froehlich" wrote:
> Warp wrote:
>
> > And this does not look like an error
> > message given by POV-Ray itself.
>
> To whom?  The 1% of very advanced users who know
> each and every error message POV-Ray can generate?

If the user isn't familiar with the error, he can search in the manual for
"user error directive" and find out about it there. That's what the
documentation is for. It could also be listed in the VFAQ.

Granted, right now such a search doesn't give clear results, but that could
easily be fixed in the manual.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3bd29aeb@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> So once and for all, it's clear that the #error stream is supposed to take
> any string, including string identifiers or functions which return strings.
>
> But it doesn't. That's a bug!

No, it takes the string. It just doesn't output the contents of the string.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3bd29f5e@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> If the user isn't familiar with the error, he can search in the manual for
> "user error directive" and find out about it there. That's what the
> documentation is for. It could also be listed in the VFAQ.
>
> Granted, right now such a search doesn't give clear results, but that could
> easily be fixed in the manual.

Please estimate the probability that a user who doesn't know about the
#error directive (which is in the documentation) will look up the reason for
an error in the documentation...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3bd29aee@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> I completely agree! But what can mere POV-Ray users do to convince a
> POV-Team member?

Remember, I am not speaking for the team, only for myself.

As for the actual problem, all you want is to get me to say "It is a bug",
but it simply is not a bug.  First of all, before considering the result, a
bug is something that is *unintentional*, BUT the problem we are discussing
is how to change the *intentional* behavior of POV-Ray.  So what remains in
the problem of getting a fatal user-defined error message to the user of the
scene file...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Please estimate the probability that a user who doesn't know about the
: #error directive (which is in the documentation) will look up the reason for
: an error in the documentation...

  IMHO there's no need to "camouflage" an #error command to look like a
POV-Ray error. Make it as different as you need from internal errors; all I'm
asking is support for printing strings exactly like in the other streams
(ie. #warning and #debug) instead of printing some SDL which can be hebrew to
the user.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Thorsten Froehlich" wrote:
> No, it takes the string. It just doesn't
> output the contents of the string.

And that's the problem. The documentation clearly says that it's supposed to
take it *and* output it. Once again I quote the same part:

"There are seven distinct text streams that POV-Ray uses for output. You may
output only to three of them."

If you still insist it isn't a bug, then what is the reason that it requires
a string, if the contents of the string isn't used for anything at all? What
is the reasoning behind this "feature"?

From another of your replies:

> Please estimate the probability that a user who
> doesn't know about the #error directive (which is
> in the documentation) will look up the reason for
> an error in the documentation...

I think it's high, but I don't have any statistics to base it on. If you
have I'd be interested in seeing them. If not, then it's pointless to
discuss this.

Instead, you you tell me why the current behavior is less confusing for the
user than the proposed behavior? If we can't find a perfect solution, then
we just ought to take the best available. From here I refer you to the reply
posted by Warp.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

We also agree that the documentation is "buggy", that is it
should be made clearer - after all, the current behavior is
against most opinions here, so it should at least be well
documented.

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

Thorsten Froehlich wrote:
> 
> No, it takes the string. It just doesn't output the contents of the string.

This very unexpected behaviour should be very clearly
stated in the docs. Right now as you said somewhere earlier,
the user can "guess" the behaviour. Doh!

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

Luckily with the source code available I can patch it to work it like I
want (if it's not too laborious).
  The PNG gamma "bug" is another example. Fortunately "patching" it just
requires commenting out two lines in png_pov.cpp.
  The bad thing is that this fixing is easily possible only for the unix
version. I can't fix the windows version... (I lack the intel compiler.)

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

You people seem to be arguing about completely different things. One side is
arguing that #error should be able to output arbitrary strings. The other
side is arguing that user error messages should not look like POV-Ray error
messages. And I agree with both of you! What is the problem here?

Post a reply to this message

Anders K. <and### [at] f2scom> wrote:
: You people seem to be arguing about completely different things.
...
: What is the problem here?

  I think that you answered your own question even before you made it... ;)

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3bd2c73b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   IMHO there's no need to "camouflage" an #error command to look like a
> POV-Ray error. Make it as different as you need from internal errors;

Ah, finally an interesting suggestion.  This sounds like something that is
possible to do easily and still avoids the problem of users taking the
output as a POV-Ray error message.

What do other people think?

    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3BD2CC78.D9A7B8D9@free.fr> , Adrien Beau <adr### [at] freefr>
wrote:

> Right now as you said somewhere earlier,
> the user can "guess" the behaviour. Doh!

???

I have been saying the opposite in each and every post in this thread!!!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3bd2b433@news.povray.org...
> In article <3bd29f5e@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
> wrote:
>
> > If the user isn't familiar with the error, he can search in the manual for
> > "user error directive" and find out about it there. That's what the
> > documentation is for. It could also be listed in the VFAQ.
> >
> > Granted, right now such a search doesn't give clear results, but that could
> > easily be fixed in the manual.
>
> Please estimate the probability that a user who doesn't know about the
> #error directive (which is in the documentation) will look up the reason for
> an error in the documentation...
>
>     Thorsten
>

A person who won't look up errors in the manual also won't read the manual for
all the little things that get asked about in the povray newsgroups all the time
that annoy those of us who do read the manual.  The stupid questions get asked,
regardless of why.  It doesn't matter if it looks like a POV-Ray error,
something completely different, or not even generate an error at all, just look
"unexpected".  I've only been posting on the povray newserver for a few weeks
and already I've quoted the manual three or four times because someone didn't
bother to look at it or do a search.

So... the estimate is that lots of users will ask lots of stupid questions...
regardless of how the program is set up or how the documentation is written.
And regardless of what generates the error.

Yes, the #error command can and/or should be distinguished from a POV-Ray error.
Perhaps something like the following, although from other discussions here, I
understand it may be asking too much:

(if in a macro)
Macro MyMacro generated a user error on line 27 of MyMacros.inc:
    Invalid parameters.  A must be between 0 and 10.

MyMacro invoked from MyPicture.pov line 58:
    object {
    MyMacro(10,20,30)<--

User #error directive hit.


(if not in a macro)
MyPicture.pov generated a user error on line 93:
    No camera was selected.  Please set MyCamera.

#error CamMessage<---

User #error directive hit.


Or something like that.  Again, I understand it may not be possible to generate
that trace, but that, I think, would be ideal.  Of course, the user generated
error message could be somehow highlited or otherwise marked so it is different
from standard POV-Ray messages.

Michael

Post a reply to this message

> >   IMHO there's no need to "camouflage" an #error command to look like a
> > POV-Ray error. Make it as different as you need from internal errors;
>
> Ah, finally an interesting suggestion.  This sounds like something that is
> possible to do easily and still avoids the problem of users taking the
> output as a POV-Ray error message.

Well, I'm glad you understand each other now. This would make a lot more
sense than the current behavior.

Post a reply to this message

"Thorsten Froehlich" wrote:
> Ah, finally an interesting suggestion.  This sounds
> like something that is possible to do easily and
> still avoids the problem of users taking the output
> as a POV-Ray error message.
>
> What do other people think?

I'm not sure how it will look, but if it means that we'll be able to direct
formatted strings to the error stream, then by all means use it! That's all
I ever asked for.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:

> I'm not sure how it will look, but if it means that we'll be able to direct
> formatted strings to the error stream, then by all means use it! That's all
> I ever asked for.

Let me see if I have this right....

The POV-Team spent a couple of years and went through countless
development versions to come up with a releasable version of
POV-Ray v3.5.

The TAG did alpha testing on no less than 10 alpha versions of
POV-Ray v3.5.

The pre-beta testers had no less than 15 versions to test and
and ask modifications for.

We are now in *public* beta testing at version #6 of what is
supposed to be a *feature locked* version of the program.

And you are still making feature requests?

When will you be satisfied enough to allow the POV-Team to move
on to other things, like v4.0 for example?

This is all rhetorical and no need for you to reply...

-- 
Ken Tyler

Post a reply to this message

> Let me see if I have this right....
>
> The POV-Team spent a couple of years and went through countless
> development versions to come up with a releasable version of
> POV-Ray v3.5.
>
> The TAG did alpha testing on no less than 10 alpha versions of
> POV-Ray v3.5.
>
> The pre-beta testers had no less than 15 versions to test and
> and ask modifications for.
>
> We are now in *public* beta testing at version #6 of what is
> supposed to be a *feature locked* version of the program.
>
> And you are still making feature requests?

That's what it looks like to me... I mean, a program can only reach a
certain level of perfection before it is "final", and people can move on to
work on the next version... I feel we should have had a final by now... How
many months/years of this do we really need? At this rate, we'll never see
4.0... Of course, I might just be overreacting... Ghaa... I've got to go
study... midterms this week...

Post a reply to this message

Doh! I reread all this thread, and sorry if my post wasn't
perfect.

Note that 

> > Right now as you said somewhere earlier,
> > the user can "guess" the behaviour. Doh!

didn't mean I accused you of being happy with the
current situation!

You said

> As the documentation is not clear what happens
> with the output, it is up to the user interpretation.

which I rewrote my (wrong?) way, from memory.

Anyway, I hope ingo is still reading this one,
because the only thing that needs to be changed
is the documentation, it seems.

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

"Ken" wrote:
> Let me see if I have this right....
>
> And you are still making feature requests?

It's not a feature request, it's a bug report.

There's a bug *somewhere* but we can't seem to agree whether it's in the
program or in the documentation.

Anyway, the latest development is that in a reply to Warp Thorsten seem
willing to fix the bug, and he asks for our opinions. And then I reply that
I think it's a great idea. And then you complain about it for some reason.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

#macro verboseFatal(stString)
  #warning stString
  #error ""
#end



verboseFatal("\n\nA Simple Solution ?\n\n")




// Povingly ,


// Philippe

Post a reply to this message

> #macro verboseFatal(stString)
>   #warning stString
>   #error ""
> #end
>
> verboseFatal("\n\nA Simple Solution ?\n\n")

    File: C:\Docs\pov\test3.pov  Line: 3
      #warning stString

      #error "" <----ERROR

    Parse Error: User error directive hit.

    Returned from renderer with error status.

Very helpful... BTW, #debug stString doesn't work either.

Post a reply to this message

> > #macro verboseFatal(stString)
> >   #warning stString
> >   #error ""
> > #end
> >
> > verboseFatal("\n\nA Simple Solution ?\n\n")

Okay, just noticed the text "A Simple Solution ?", but it was way above the
error message (even above a horizontal rule), and I think most users
wouldn't have noticed it.

Post a reply to this message

On Sun, 21 Oct 2001 17:15:21 +0200, Thorsten Froehlich wrote:
>In article <3bd2c73b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>
>>   IMHO there's no need to "camouflage" an #error command to look like a
>> POV-Ray error. Make it as different as you need from internal errors;
>
>Ah, finally an interesting suggestion.  This sounds like something that is
>possible to do easily and still avoids the problem of users taking the
>output as a POV-Ray error message.
>
>What do other people think?

I think it's a good idea.  I certainly always assumed that #error would
print what I asked it to before aborting; if it has to put little flashy
warning signs around the error, that's okay, but it should definitely do
what it looks like it does.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

in news:3BD33830.7DF64ED6@free.fr Adrien Beau wrote:

> Anyway, I hope ingo is still reading this one,

He does and waits until it comes to a conclusion: will Thorsten make 
the proposed changes, it sounds ggod, and what should be changed 
exactly in the doc.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message