"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48d700f7@news.povray.org...
> Jim Holsenback wrote:
>> I did change ALL distro scenes that called any glass textures the old 
>> way.
>
> I think you missed woodbox.pov then:] (either that or I didn't update
> it for some reason).

I still have modified scenes on my system and it (woodbox.pov) looks like 
it's been done on my end. I connected to the ftp site and in 
jim/scenes/advanced woodbox.pov has been changed as well.

> While I'd like to see a warning issued, the problem would be that
> anyone with a pre-3.7 scene loading the include file (even if they
> don't use the glass textures) would get the warning ... I expect some
> scenes out there do include files that they don't use, and would thus
> get this warning. Also, anyone running an old scene without a #version
> set would get a parse failure on the missing textures.
>
> I think we need to provide both for the meantime. Perhaps we also then
> need something like the 'deprecated' warning that is available in
> compilers; we can declare something deprecated (via SDL) and if it is
> used in a scene the parser spits out a warning.
>
> -- Chris

Perhaps I jumped the gun abit. Things were flying pretty fast and when I 
floated the idea of addressing this issue it didn't seem that anyone had any 
strong feelings one way or another, so I pulled the trigger. If I could have 
a few days to think about how to address this to everyones satisfaction I'd 
like to take ownership of putting this issue to rest. In the meantime if 
there are anymore specific considerations I should be aware of ..... let 'em 
fly!

Cheers

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48d700f7@news.povray.org...
> I think you missed woodbox.pov then:] (either that or I didn't update
> it for some reason).

another thought .... woodbox.pov will still issue the I_Glass warning if the 
modified glass.inc and glass_old.inc files are not in place. Those file are 
on the ftp site in the  jim/include directory.

Ciao

Post a reply to this message

Jim Holsenback wrote:
> I still have modified scenes on my system and it (woodbox.pov) looks like 
> it's been done on my end. I connected to the ftp site and in 
> jim/scenes/advanced woodbox.pov has been changed as well.

You are correct; it appears the updated installer I made had the old
file in it for some reason. Apologies for getting it wrong.

> Perhaps I jumped the gun abit. Things were flying pretty fast and when I 
> floated the idea of addressing this issue it didn't seem that anyone had any 
> strong feelings one way or another, so I pulled the trigger. If I could have 
> a few days to think about how to address this to everyones satisfaction I'd 

Sure, feel free to think it over. I think we need to move forward on
stuff like this without the fear of being bound to the past, while at
the same time keeping in mind that one of the impediments to upgrading
any software is if a user's old files don't work (properly). Hence we
need to balance things and provide backwards compatibility where possible.

If (as it appears to be the case) the SDL as it stands doesn't provide
a clean way of deprecating existing constructs while still permitting
their use, then we need to enhance the SDL. I'm inclined to add such a
means. For example:

  #declare I_Glass4=
    deprecated once "... some message goes here ..."
    interior {
      ior 1.5
      fade_distance 2.0
      fade_power 1001
    }

if we did it this way, for example, the #declared item is known by the
parser to be deprecated: this generates no warning during the parse of
the #declare itself (or even if the #declare is used in another
#declare), but if it is used in an actual object, the message
associated with it is displayed (if the 'once' keyword is present,
it's only displayed once per parse, otherwise it's displayed each time
it's used in an object).

I'm not saying it has to be done this way; it's just one thing that
comes to mind. It would require the parser to track the deprecated
status of each #declared item (passing up the state if a new declare
inherits a deprecated declare, and so forth), which isn't as clean as
I'd like it to be. The other option is to display the warning anytime
the declare is used (even if in another declare, which means we have
to ensure we don't use such declares as part of something else in the
same standard include file as this would trigger the warning even if
the end-user didn't use the #declared item).

-- Chris

Post a reply to this message

Chris Cason wrote:

> It would require the parser to track the deprecated
> status of each #declared item (passing up the state if a new declare
> inherits a deprecated declare, and so forth), which isn't as clean as
> I'd like it to be.

If the SDL could be changed to allow calling parameterless macros 
without parantheses, it might be possible to do something like

#declare I_Glass4_Deprecated =
     interior {
       ior 1.5
       fade_distance 2.0
       fade_power 1001
     }

#macro I_Glass4()
   #warning "I_Glass4 is deprecated"
   I_Glass4_Deprecated
#end

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48d874f9$1@news.povray.org...
> I think we need to move forward on
> stuff like this without the fear of being bound to the past, while at
> the same time keeping in mind that one of the impediments to upgrading
> any software is if a user's old files don't work (properly). Hence we
> need to balance things and provide backwards compatibility where possible.

cool .... we're on the same page then.

> If (as it appears to be the case) the SDL as it stands doesn't provide
> a clean way of deprecating existing constructs while still permitting
> their use, then we need to enhance the SDL. I'm inclined to add such a
> means. For example:
>
>  #declare I_Glass4=
>    deprecated once "... some message goes here ..."
>    interior {
>      ior 1.5
>      fade_distance 2.0
>      fade_power 1001
>    }

> if we did it this way, for example, the #declared item is known by the
> parser to be deprecated: this generates no warning during the parse of
> the #declare itself (or even if the #declare is used in another
> #declare), but if it is used in an actual object, the message
> associated with it is displayed (if the 'once' keyword is present,
> it's only displayed once per parse, otherwise it's displayed each time
> it's used in an object).

How big of a deal to do this? Giving the parser the means to do this could 
be useful for furture change issues as well right? This issue (I_Glass) 
isn't the first time and I'm sure it wouldn't be the last, so I kind of like 
this idea at first glance.

> I'm not saying it has to be done this way; it's just one thing that
> comes to mind. It would require the parser to track the deprecated
> status of each #declared item (passing up the state if a new declare
> inherits a deprecated declare, and so forth), which isn't as clean as
> I'd like it to be. The other option is to display the warning anytime
> the declare is used (even if in another declare, which means we have
> to ensure we don't use such declares as part of something else in the
> same standard include file as this would trigger the warning even if
> the end-user didn't use the #declared item).
>
> -- Chris

I've pseudo coded an idea but haven't had the time to see if it might lead 
anywhere. Basically the idea would use a function to return the state of a 
toggle so we could conditionally provide a warning, but your suggestion has 
me thinking that my idea is more of a patch than a solution.

Jim

Post a reply to this message

Jim Holsenback wrote:
> How big of a deal to do this? Giving the parser the means to do this could 
> be useful for furture change issues as well right? This issue (I_Glass) 
> isn't the first time and I'm sure it wouldn't be the last, so I kind of like 
> this idea at first glance.

Yes, it would be: this is the primary reason why I'm considering it.
I've prototyped this in the parser and it seems to be working OK so
most likely I'll include it in the next beta. I'll get an early copy
to you so you can add support for the keyword in the include files if
you like.

-- Chris

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:48a98a0d@news.povray.org...
>> Stephen & Sabrina: I'm done with all my edits and have rendered all the 
>> files in the textures directory.

you guys have been silent for awhile ..... any status update?

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48db069d$1@news.povray.org...
> Jim Holsenback wrote:
>> How big of a deal to do this? Giving the parser the means to do this 
>> could
>> be useful for furture change issues as well right? This issue (I_Glass)
>> isn't the first time and I'm sure it wouldn't be the last, so I kind of 
>> like
>> this idea at first glance.
>
> Yes, it would be: this is the primary reason why I'm considering it.
> I've prototyped this in the parser and it seems to be working OK so
> most likely I'll include it in the next beta. I'll get an early copy
> to you so you can add support for the keyword in the include files if
> you like.
>
> -- Chris

thanks that would be great!

Post a reply to this message

Jim Holsenback wrote:
> thanks that would be great! 

Ok, it's in the FTP dir (pvengine.zip). Note that this has some other
changes related to paths: you may need to copy your standard scenes,
include, ini, and insert menu files to 'My Documents\POV-Ray\v3.7'.

Syntax is as follows:

  #declare deprecated Col_Glass_Old=color rgbf <0.8, 0.9, 0.85, 0.85>;
  #declare deprecated once Col_Glass_Old=... etc
  #declare deprecated "Some message" Col_Glass_Old=... etc
	
A deprecated identifier generates no message at the time it is declared: a
warning is only issued if it is used.
	
If the optional 'once' keyword is present it must immediately follow the
'deprecated' keyword and indicates that the warning should only be
displayed once per parse.
	
If the optional message string is present, it will be used as the warning
to be displayed if the identifier is used. Otherwise, a message of the form
"Identifier 'Col_Glass_Old' was declared deprecated." is used.
	
An identifier is considered 'used' if it is referenced anywhere (even if in
another #declare).

-- Chris

Post a reply to this message

Jim Holsenback wrote:
> you guys have been silent for awhile ..... any status update? 

NB I have files from all three of you now: I think the set is basically
complete.

thanks for the help folks!

-- Chris

Post a reply to this message