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