beta32 bugs
-----------------------------------------------------------------------------
In windows versions the controls for the render window are non-functional.
(Keep above main, Get focus on creation, and Hide when minimized)
-----------------------------------------------------------------------------
Using facets as a controlling pattern for a normal map results in an
unspecified fatal error, this should be caught at parse time to give a
specific error.
-----------------------------------------------------------------------------
Malformed nested #declares are not caught at parse time, instead they can
terminate inside following control structures, causing some objects not to
render.
-----------------------------------------------------------------------------
Overlapping partially transparent objects can result in speckled shadows.
Rays cast at coincident surfaces should return one of the two textures,
and not "leak" untextured rays.
-----------------------------------------------------------------------------
Texture maps containing reflective textures may cause an exception and
full crash, w/ optional dump.
-----------------------------------------------------------------------------
Partial transparency can cause blocky (32x32) blotches in transparent
regions.
-----------------------------------------------------------------------------
Array.inc and subsurface.pov are in read only mode.
-----------------------------------------------------------------------------
In Vista (x64) the POV (x64) installer fails to ask for admin privleges,
so the program files end up in
C:\Users\%name%\AppData\Roaming\POV-Ray.
After getting install privleges they should end up in
C:\Program Files\POV-Ray
The modifiable files end up in C:\Users\%name%\Documents\POV-Ray
as intended. It's usable this way, just unexpected.

Post a reply to this message

> In windows versions the controls for the render window are non-functional.
> (Keep above main, Get focus on creation, and Hide when minimized)
Oops, that's 3.6 not Beta.

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> > In windows versions the controls for the render window are non-functional.
> > (Keep above main, Get focus on creation, and Hide when minimized)
> Oops, that's 3.6 not Beta.

My 3.6 works fine - I just tested them.  It's a self-compiled version but IIRC
I'm using the original editor dll.
Charles

Post a reply to this message

>> > In windows versions the controls for the render window are 
>> > non-functional.
>> > (Keep above main, Get focus on creation, and Hide when minimized)
>> Oops, that's 3.6 not Beta.
>
> My 3.6 works fine - I just tested them.  It's a self-compiled version but 
> IIRC
> I'm using the original editor dll.
> Charles

Hmm, I did observe this today, hmm let me check...
I think what is going on is that you need to exit for the changes to take
effect, so it can appear that the behavior isn't right.

Post a reply to this message

Tim Attwood wrote:
> In Vista (x64) the POV (x64) installer fails to ask for admin privleges,

Is this when you select "install for all users"?

-- Chris

Post a reply to this message

Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> Malformed nested #declares are not caught at parse time, instead they can
> terminate inside following control structures, causing some objects not to
> render.

  Can you give an example of this?

  The way povray parses SDL, especially things like nested declares, may not
always be completely intuitive, but not necessarily buggy.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood nous illumina en ce 2009-04-05 19:02 -->
> beta32 bugs
> ----------------------------------------------------------------------------- 
> 
> In windows versions the controls for the render window are non-functional.
> (Keep above main, Get focus on creation, and Hide when minimized)
> ----------------------------------------------------------------------------- 
> 
> Using facets as a controlling pattern for a normal map results in an
> unspecified fatal error, this should be caught at parse time to give a
> specific error.
> ----------------------------------------------------------------------------- 
> 
> Malformed nested #declares are not caught at parse time, instead they can
> terminate inside following control structures, causing some objects not to
> render.
> ----------------------------------------------------------------------------- 
> 
> Overlapping partially transparent objects can result in speckled shadows.
> Rays cast at coincident surfaces should return one of the two textures,
> and not "leak" untextured rays.
> ----------------------------------------------------------------------------- 
> 
> Texture maps containing reflective textures may cause an exception and
> full crash, w/ optional dump.
> ----------------------------------------------------------------------------- 
> 
> Partial transparency can cause blocky (32x32) blotches in transparent
> regions.
> ----------------------------------------------------------------------------- 
> 
> Array.inc and subsurface.pov are in read only mode.
> ----------------------------------------------------------------------------- 
> 
> In Vista (x64) the POV (x64) installer fails to ask for admin privleges,
> so the program files end up in
> C:\Users\%name%\AppData\Roaming\POV-Ray.
> After getting install privleges they should end up in
> C:\Program Files\POV-Ray
> The modifiable files end up in C:\Users\%name%\Documents\POV-Ray
> as intended. It's usable this way, just unexpected.
> 
The ini files are replaced with every version change.
You loose any change that you may have made to them.

After any new version install, you have to go back and remake any customization, 
including library paths, permited output path, image file format, display gamma 
settings, image gamma, and such.


-- 
Alain
-------------------------------------------------
I believe that banking institutions are more dangerous to our liberties than
standing armies. Already they have raised up a monied aristocracy that has
set the government at defiance. The issuing power should be taken from the
banks and restored to the people to whom it properly belongs.
Thomas Jefferson

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> beta32 bugs

trace() and inside() on julia objects still crash POV...

Cheers,
Edouard.

Post a reply to this message

> Is this when you select "install for all users"?

No, install for single user...

Post a reply to this message

>  Can you give an example of this?
>
>  The way povray parses SDL, especially things like nested declares, may 
> not
> always be completely intuitive, but not necessarily buggy.

Sure, I realize it's been this way for a while...
essentially since it's ok to have other declares and
partial control structures inside of a declare there's no
check being done inside the declare until it is used.
In this example if Wierd contains the code up until
the pass_text object, then the parsing should fail
when the first #end is parsed, instead the #end is
matched to #while inside of the value of the Wierd #declare.

// misformed #declare
#declare Weird = #declare Aval = 1;

// other properly formed statements
#declare PigVal = pigment {rgb <0,0,0>};
#declare ObjVal = sphere {<0,0,0>,1};

#if (true=true)
#local c=0;
#while (c=0)

// this object ends the misformed #declare and doesn't render
object {pass_text}

// this object renders normally
object {fail_text}

#local c=1;
#end
#end

Post a reply to this message

> The ini files are replaced with every version change.
> You loose any change that you may have made to them.
>
> After any new version install, you have to go back and remake any 
> customization, including library paths, permited output path, image file 
> format, display gamma settings, image gamma, and such.

Right, but the install program says it's going to install
the binaries to C:\Program Files and doesn't. Vista
redirects it to the virtual store because it doesn't have
installation privleges. The ini files and customizable stuff
goes to the documents pov folder as intended.

Post a reply to this message

> trace() and inside() on julia objects still crash POV...

Ah, I missed that one.

Post a reply to this message

Edouard wrote:
> trace() and inside() on julia objects still crash POV...

This made me laugh. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> // misformed #declare
> #declare Weird = #declare Aval = 1;

> // other properly formed statements
> #declare PigVal = pigment {rgb <0,0,0>};
> #declare ObjVal = sphere {<0,0,0>,1};

> #if (true=true)
> #local c=0;
> #while (c=0)

> // this object ends the misformed #declare and doesn't render
> object {pass_text}

> // this object renders normally
> object {fail_text}

> #local c=1;
> #end
> #end 

  As I said, the way the parser works is not always completely intuitive.

  Your example is a perfect example. It makes perfect sense when you know
how the parsing of #declares works, even if this kind of parsing sometimes
results in odd behavior like in your example.

  What is happening is that when the parser sees the very first "#declare",
it then parses an identifier name and a '='. After this it calls recursively
itself, asking itself for something which can be assigned to an identifier.
The very first thing which pops up is that first "object" block. Thus that
gets assigned to the first identifier.

  Of course since the parser is calling itself recursively, if there are
any other #-commands in-between, those will get parsed as their own entities,
before the parser gets to that first "object" block.

  As said, the behavior is not buggy per se, but a side-effect of the
recursive nature of the parser. Sometimes these side-effects produce
unintuitive results.

-- 
                                                          - Warp

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:

> essentially since it's ok to have other declares and
> partial control structures inside of a declare there's no
> check being done inside the declare until it is used.

Here's youre wrong assumption: Only macros defer execution of "preprocessing"
statements. #declares just defer the "materializing" of already built scene
objects by instead storing them in variable space.

That's the main difference between #declares and macros, which manifest in code
like:

#declare Pos = <1,2,3>;
#declare MySphere1 = sphere { Pos, 1 }

#declare Pos = <4,5,6>;
#declare MySphere2 = sphere { Pos, 1 }

object { MySphere1 }
object { MySphere2 }

as opposed to:

#declare Pos = <1,2,3>;
#macro MySphere1() sphere { Pos, 1 } #end

#declare Pos = <4,5,6>;
#macro MySphere2() sphere { Pos, 1 } #end

Post a reply to this message

>> // misformed #declare
>> #declare Weird = #declare Aval = 1;
>
>> // other properly formed statements
>> #declare PigVal = pigment {rgb <0,0,0>};
>> #declare ObjVal = sphere {<0,0,0>,1};
>
>> #if (true=true)
>> #local c=0;
>> #while (c=0)
>
>> // this object ends the misformed #declare and doesn't render
>> object {pass_text}
>
>> // this object renders normally
>> object {fail_text}
>
>> #local c=1;
>> #end
>> #end
>
>  As I said, the way the parser works is not always completely intuitive.
>
>  Your example is a perfect example. It makes perfect sense when you know
> how the parsing of #declares works, even if this kind of parsing sometimes
> results in odd behavior like in your example.
>
>  What is happening is that when the parser sees the very first "#declare",
> it then parses an identifier name and a '='. After this it calls 
> recursively
> itself, asking itself for something which can be assigned to an 
> identifier.
> The very first thing which pops up is that first "object" block. Thus that
> gets assigned to the first identifier.
>
>  Of course since the parser is calling itself recursively, if there are
> any other #-commands in-between, those will get parsed as their own 
> entities,
> before the parser gets to that first "object" block.
>
>  As said, the behavior is not buggy per se, but a side-effect of the
> recursive nature of the parser. Sometimes these side-effects produce
> unintuitive results.

The problem isn't that Weird is being set to an object identifier,
the problem is that #end (which is outside the declare) is being
associated with #while (inside the declare). I think most people
would expect the scope of control structures inside of a declare
to be inside that declare. I guess you could do things like ...

#local c = 0;
#declare Third = #declare Second = #declare First =
#while (c<3) object {pass_text} #local c=c+1; #end

... with the current parsing, but it just seems bad to encourage
difficult to read code. The first example is more of a typical typo,
"oops I paste in a declare with the value". IMHO this is one
of those "That's not a bug, it's a feature!" things.

Post a reply to this message

> Here's youre wrong assumption: Only macros defer execution of 
> "preprocessing"
> statements. #declares just defer the "materializing" of already built 
> scene
> objects by instead storing them in variable space.

I understand how it works.

I just think that a declare should look for closures of control structures 
after
finding an identifier. I don't think you should just queue a pointer to the 
next
identifier. It works, but it's hardly what most people expect. In 
particular,
in a large file it can be very hard to find a typo (user error) related to 
this
behavior since it raises no parsing errors. It would be reasonable to add
warnings on use of declares containing control structures, even if it's 
decided
not to change the behavior.

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> I just think that a declare should look for closures of control structures
> after
> finding an identifier. I don't think you should just queue a pointer to the
> next
> identifier. It works, but it's hardly what most people expect.

That's just because they're not very used to this type of parsers anymore.

Why should a #declare look for closures of control structures? After all, it's
just a dumb #declare.

That's just the basic idea behind POV's current SDL:

You have a very straightforward SDL, with (comparatively) clear structure that
can easily be checked.

On top of that sits some preprocessor, which just freely scrambles the input
file to build new statements, according to statements embedded in the input
file. Which gives it the potential to make it an ugly mess.


This two-tier approach is quite outdated of course, but that's just how things
were when POV's SDL was conjured up. Or, probably more likely (don't know the
history), when it was decided to add programming capabilities to the SDL.

Time for a new SDL to be designed, which hopefully will abandon the preprocessor
concept, and instead seamlessly integrate control flow into the scene
description, enforcing stricter (and therefore easier to check) rules for the
nesting of stuff.


> In
> particular,
> in a large file it can be very hard to find a typo (user error) related to
> this
> behavior since it raises no parsing errors. It would be reasonable to add
> warnings on use of declares containing control structures, even if it's
> decided
> not to change the behavior.

Why that? What's wrong with

#local MyBlob = {
  #local i = 0;
  #while (i < 10)
    sphere { VRand(Rnd)*10, rand(Rnd) ... }
    #local i = i + 1;
  #end
}

Impossible without nesting of #local statements.

Yes, this example nests nicely. But checking for the nesting isn't so easy,
given the current SDL parser structure.

And there may be examples where nesting isn't desired. Which is bad programming
style if I'm asked, but it seems like people do it occasionally.

Post a reply to this message

> Why that? What's wrong with
> 
> #local MyBlob = blob {
>  #local i = 0;
>  #while (i < 10)
>    sphere { VRand(Rnd)*10, rand(Rnd) ... }
>    #local i = i + 1;
>  #end
> }
Sure, nothing wrong that way, #local MyBlob
sets a pointer to a blob object. Maybe declares
should expect some identifier, object, or value 
as the following token, and raise a warning or 
error if the next token is a control structure.

Here's a good example that will actually crash
because of not checking for this.

#while (c=0)
  #local c = #end c+1;

This parses fine, and crashes because of it.
The #while attempts to evaluate the pointer c,
but the pointer c doesn't point to anything yet.

Post a reply to this message

Le 08.04.2009 22:13, Tim Attwood nous fit lire :
>> trace() and inside() on julia objects still crash POV...
> 
> Ah, I missed that one.

For trace on julia, I have posted a suggestion of correction (issue is that the IStack
of
the parser thread is not resized when the fractal object updates the limit for IStack
on
the thread-data. Further threads will create IStack based on that limit, but trace()
is
called by the parser thread, which default to a 0-sized IStack. Therefore
coredump/EFault
to access an array of size 0/Null pointer)

I did not know about inside().

Post a reply to this message