POV-Ray : Newsgroups : povray.beta-test : #error bug Server Time
30 Jul 2024 22:27:03 EDT (-0400)
  #error bug (Message 21 to 30 of 43)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Thorsten Froehlich
Subject: Re: #error bug
Date: 21 Oct 2001 07:40:35
Message: <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

____________________________________________________
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

From: Thorsten Froehlich
Subject: Re: #error bug
Date: 21 Oct 2001 07:47:13
Message: <3bd2b5c1@news.povray.org>
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

From: Warp
Subject: Re: #error bug
Date: 21 Oct 2001 09:01:48
Message: <3bd2c73b@news.povray.org>
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

From: Rune
Subject: Re: #error bug
Date: 21 Oct 2001 09:20:18
Message: <3bd2cb92@news.povray.org>
"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

From: Adrien Beau
Subject: Re: #error bug
Date: 21 Oct 2001 09:22:14
Message: <3BD2CC02.2A7D33E5@free.fr>
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

From: Adrien Beau
Subject: Re: #error bug
Date: 21 Oct 2001 09:24:13
Message: <3BD2CC78.D9A7B8D9@free.fr>
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

From: Warp
Subject: Re: #error bug
Date: 21 Oct 2001 10:37:18
Message: <3bd2dd9e@news.povray.org>
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

From: Anders K 
Subject: Re: #error bug
Date: 21 Oct 2001 10:39:02
Message: <3bd2de06@news.povray.org>
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

From: Warp
Subject: Re: #error bug
Date: 21 Oct 2001 10:58:21
Message: <3bd2e28c@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: #error bug
Date: 21 Oct 2001 11:15:25
Message: <3bd2e68d@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.