 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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] free fr 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
|
|
| |
| |
|
|
|
|
| |
