Re: [Openexr-user] CTL bug/implementation issue

[gga]

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
address@hidden

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy