Hello/Hi,

While I was making a new scene with POVRay, I found (by sheer luck) something
weird, with the following scene:

#version 3.7;

global_settings{ assumed_gamma 1.0 }

background{ color srgb 1 }

camera{
    location < 1, 1, -2 >
    look_at <0, 0.5, 0>
}

light_source{ < 1, 2, -3 > * 1000000 color srgb 1 }

#box{< 0, 0, 0>, < 1, 7/47, 1 > pigment{ color srgb < 1, 1, 0> } }

//End of file

In this .pov file you can notice there's that '#box' keyword that doesn't
prevent the POVRay parser from making a new image (I can see a yellow box in a
white background). Before I report that bug , I wondrered if there was a
preprocessor keyword in the Scene Description Language which name is box, but I
didn't find anything in google or qwant. The above scene has been tested with
povray 3.7.0.8 unofficial and povray 3.8.0 alpha unofficial both compiled with
g++-9.2.0. The end line type of the scene file is CRLF and working renders were
done with "Lubuntu 19.10 eoan ermine".

Post a reply to this message

hi,

"Warren" <nomail@nomail> wrote:
> While I was making a new scene with POVRay, I found (by sheer luck) something
> weird, with the following scene:
>
> #version 3.7;
>
> global_settings{ assumed_gamma 1.0 }
>
> background{ color srgb 1 }
>
> camera{
>     location < 1, 1, -2 >
>     look_at <0, 0.5, 0>
> }
>
> light_source{ < 1, 2, -3 > * 1000000 color srgb 1 }
>
> #box{< 0, 0, 0>, < 1, 7/47, 1 > pigment{ color srgb < 1, 1, 0> } }
>
> //End of file
>
> In this .pov file you can notice there's that '#box' keyword that doesn't
> prevent the POVRay parser from making a new image (I can see a yellow box in a
> white background). Before I report that bug , I wondrered if there was a
> preprocessor keyword in the Scene Description Language which name is box, but I
> didn't find anything in google or qwant. The above scene has been tested with
> povray 3.7.0.8 unofficial and povray 3.8.0 alpha unofficial both compiled with
> g++-9.2.0. The end line type of the scene file is CRLF and working renders were
> done with "Lubuntu 19.10 eoan ermine".

I remember reading (in one of the newsgroup posts) about an issue/bug regarding
the '#default {}' directive, which also works without the '#'.  fwiw:

#version 3.7;
#global_settings{ assumed_gamma 1.0 }
#background{ color srgb 1 }
#camera{
    location < 1, 1, -2 >
    look_at <0, 0.5, 0>
}
#light_source{ < 1, 2, -3 > * 1000000 color srgb 1 }
#box{< 0, 0, 0>, < 1, 7/47, 1 > pigment{ color srgb < 1, 1, 0> } }

too renders the image (3.8.0-alpha.10064268.unofficial).


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> I remember reading (in one of the newsgroup posts) about an issue/bug regarding
> the '#default {}' directive, which also works without the '#'.  fwiw:

Yes, and there was more than that as well.

see:
http://news.povray.org/povray.general/thread/%3Cweb.5d8f1cd3fe1f4a21e462584c0%40news.povray.org%3E/?mtop=428173&moff=5

3) And a lesson for me!
Saw #object (which you shouldn't need for the trace) and #cylinder;
Thought, "Does that really work?" It does! You can also stick '#' on the
end on some lines or code #declare CylinderZ = #cylinder {} and nary a
peep or problem from the parser - new or old versions. The usual and
recommended syntax is object {} and cylinder {}.

A declare without the leading # works too but we get:

File 'tmp.pov' line 40: Parse Warning: Should have '#' before 'declare'.
File 'tmp.pov' line 40: Possible Parse Error: 'declare' should be changed to
  '#declare'. Future versions may not support 'declare' and may require
  '#declare'.

Given this warning, I'd think we should be getting one on #object {} and
the like too as the other side of the syntax change push - now that I
understand there is another side.

Suppose this behavior related to Christoph's recommendation to me back
in February to use default {} rather than #default {} though it's the
latter which is still in the documentation. The idea, as I understand
it, is to get to where the #<token> is used only with SDL language
control elements.



and



If you have an example which results in an actual error at parse time,
I'd like to get it.

I have a collection of parser test cases and I spent time yesterday
capturing/creating parser test cases for these '#' variants. I didn't
come up with anything that generated an actual parse error - or render
problem - only the warnings above.

I did come up with a case with isolated #s ahead of a bare 'declare'
which did NOT generate the warnings above (I found a parser bug) though
the render result was still fine.

.....

Unsure if you were agreeing we should be getting such warnings, or
saying POV-Ray does generate such a warning. If the latter, I never saw
that while trying different things. If warnings for #Primitive_Name do
sometimes happen, I'd like an example test case for my collection.

Also had the thought last night, Does say '#accuracy 0.001' work..? It
does.



So, yes - there's still a lot of work that needs to be done with the parser.
And that may explain why clipka's locked himself in an isolation chamber for
quite some time now.   If that's what he's actually doing, then he may need
years of therapy...

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > I remember reading (in one of the newsgroup posts) about an issue/bug regarding
> > the '#default {}' directive, which also works without the '#'.  fwiw:
>
> Yes, and there was more than that as well.
>
> see:
>
http://news.povray.org/povray.general/thread/%3Cweb.5d8f1cd3fe1f4a21e462584c0%40news.povray.org%3E/?mtop=428173&moff=
5


thanks for digging this out, sad to say I'd forgotten the a lot (most?) of the
details.


> ...
> If you have an example which results in an actual error at parse time,
> I'd like to get it.

I happened to come across an error a few days ago  :-), I'll try and reproduce
it with a little scene, to post.


> I have a collection of parser test cases and I spent time yesterday
> capturing/creating parser test cases for these '#' variants. I didn't
> come up with anything that generated an actual parse error - or render
> problem - only the warnings above.
>
> I did come up with a case with isolated #s ahead of a bare 'declare'
> which did NOT generate the warnings above (I found a parser bug) though
> the render result was still fine.
>
> .....
>
> Unsure if you were agreeing we should be getting such warnings, or
> saying POV-Ray does generate such a warning. If the latter, I never saw
> that while trying different things. If warnings for #Primitive_Name do
> sometimes happen, I'd like an example test case for my collection.
>
> Also had the thought last night, Does say '#accuracy 0.001' work..? It
> does.

I think I'm mostly with Alain on this, both '#object' and '#accuracy' are ..
objectionable imo.


> So, yes - there's still a lot of work that needs to be done with the parser.
> And that may explain why clipka's locked himself in an isolation chamber for
> quite some time now.   If that's what he's actually doing, then he may need
> years of therapy...

when was the last time?  must be a year by now.


regards, jr.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> If you have an example which results in an actual error at parse time,
> I'd like to get it.
>
> I have a collection of parser test cases and I spent time yesterday
> capturing/creating parser test cases for these '#' variants. I didn't
> come up with anything that generated an actual parse error - or render
> problem - only the warnings above.


File 'be_error.pov' line 25: Possible Parse Error: Uncategorized error thrown at
 parser/symboltable.cpp line 157.
Fatal error in parser: Uncategorized error.
Render failed

file 'be_error.pov':
----------<snip>----------
#version 3.8;

global_settings {assumed_gamma 1}

#if (0)
#macro AA()
  #local d_ = dictionary;
  #local d_.k  = 1;
  d_
#end
#else
#macro AA()
  #local k_ = 1;
dictionary {.k: k_}
#end
#end

#macro BB(dict_)
  #debug concat("key k = ",str(dict_.k,0,0),"\n")
#end

#macro CC()
  #local d_ = AA();
  BB(d_)
#end

CC()

----------<snip>----------

the 'else' branch works as expected.

hth.


regards, jr.

Post a reply to this message

>> jr and Bald Eagle have written [...].

I wasn't aware of all that at all :-(.

Post a reply to this message

hi,

"Warren" <nomail@nomail> wrote:
> >> jr and Bald Eagle have written [...].
>
> I wasn't aware of all that at all :-(.

on the bright side, as documented, everything works.  (mostly ;-))


regards, jr.

Post a reply to this message