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

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48db9305@news.povray.org...
> 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'.

Thanks Chris! I'm all set .... still have my old notes so I know what files 
need to be looked at (14 scene files and 1 include). Barring diversions on 
my end I should be able to wrap this up before the end of this weekend.

Cheers

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48db9305@news.povray.org...
> 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'.

I've uploaded the files to the FTP dir (glass/include & glass/scenes) not 
all the scene files needed additional changes.
Basically I deprecated the textures in glass_old.inc and added appropriate 
comments to the file header.

Jim

Post a reply to this message

Jim Holsenback wrote:
> I've uploaded the files to the FTP dir (glass/include & glass/scenes) not 
> all the scene files needed additional changes.
> Basically I deprecated the textures in glass_old.inc and added appropriate 
> comments to the file header.

thanks for that, looks good.

-- Chris

Post a reply to this message