> 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