Florian Kainz wrote: > Hi Gonzalo, > > in CTL you fix duplicate names the same way as in C: > either make the variable names unique, for example, by > using a prefix, or, if you want a variable that is shared > by two transforms, move the variable into a separate CTL > module that is then imported by both transforms. > > We may at some point add support for unnamed namespaces. > > The duplicate variable in transform_DPX_EXR.ctl and > transform_RRT.ctl is an oversight and should be fixed. >
Sounds reasonable. Currently the main headache is that this prevents a totally valid module from loading otherwise (and the error is quite cryptic to the user, too). As ctl files are to be used mostly as runtime code unlike C, it might be better to follow the queue from scripting languages and just output a warning keeping either the original or new value. If the duplicated constant variable is then misused only *then* raise an exception. For example, taking a queue from ruby which is a scripting language with (pseudo) constants: $ irb irb> A = 20 => 20 irb> A = "hello" (irb):2: warning: already initialized constant A => "hello" but the code loads and keeps working (unless A is later misused due to, for example, a change in type like the example above): irb> A + 50 TypeError: can't convert Fixnum into String On another note: I haven't looked too deep into the CTL implementation yet, but... Is there currently any way to output bytecodes or, better yet, encode the ctl code? One of the original discussions on this list mentioned that as a potential feature, so that, say, if ILM wanted to share data with me, I would be able to use their ctl files, but, at the same time, ILM could keep their proprietary color transforms secret (at least without me doing some serious reverse engineering). -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy _______________________________________________ Openexr-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/openexr-user
