[Radiance-general] Re: CVS, ANSI, C++

[Randolph Fritz]

[Copied to both lists.  Until a few more people--including Greg
Ward!--sign up for radiance-dev I don't feel right about using it
exclusively for this discussion.]

On Sun, Jun 09, 2002 at 08:02:07AM -0700, Greg Ward wrote:
> I like what Randolph had to say about code conversion.

Thank you.

> I never bothered to take them out because they still seem to compile, 
> and they don't affect anything (other than taking up a bit of space on 
> everyone's systems) since Radiance programs that are never run never 
> interact with the rest of the codebase...

I agree...but I don't see good reasons to preserve some of them
through an extensive rewrite.  If they're hard to ANSIfy, I think we'd
be advised to just put them aside.

> We're probably looking at a week or two of one programmer's time, and a 
> few hours from each volunteer.  Who wants to step forward?

I can offer a few hours, but exactly when is uncertain.

> An afterthought to my last message.  The process of ANSI-fication should 
> probably include a merge of the Desktop Radiance version, at least 
> insofar as supporting Windows compilation as well.  

How do people feel about Cygwin/gcc
<http://sources.redhat.com/cygwin/> under Windows?  I don't know the
package, and it probably still needs an MS compiler for the header
files, but otherwise we can use the familiar Unix tools on Windows.  I
have, however, only a bit of experience with cygwin, and don't how
well it works for a large project.

Georg Mischler:
> It could also be interesting to consider another implementation
> framework for all the helper programs circulating around the actual
> Radiance core. Some of the csh scripts have been rewritten in C for
> Windows, with limited flexibility and robustness. My personal
> favourite language for this kind of task would be Python (with some
> parts already existing).

I like this very much, but am a bit concerned about requiring all
users to install Python libraries.  Also, some users will want other
scripting languages; TCL, Perl, and (gack!) Visual Basic are likely
candidates.  Ummm...probably Mathematica.

> The problem of platform specific code variations is actually
> independent from the ANSI conversion. In part, the ANSI standard was
> supposed to reduce those incompatiblities, but succeeded in that
> point only to a certain degree. I have no experience with GNU
> autoconf myself, but maybe that would be a reasonable way to
> eliminate the need to actually know which platform has what kind of
> quirks.

Autoconf...scares me.  It's one of the most difficult scripting
languages and it actively encourages #ifdef-laden code.  Personally, I
favor the Kernighan and Pike (*The Practice of Programming*) approach
to portability; write the base code portably, and bottle up the OS
dependencies in separate libraries and APIs.

Peter Apian-Bennewitz <apian@pab-opto.de>:
> Thoughts on a rewrite were founded on the limited and cumbersome
> "interface" for extending the core rendering. 
> [...]
> However, that interface is not changed solely by prototyping functions.
> Doing more than that risks new bugs- well, we'll get them out. Maybe
> there's a core structure between just-prototypes and a full rewrite ?

Hmmmm...Radiance plug-ins.  Most Unices support some version of
dynamic loading these days.  Windows does.  I don't think Plan 9 does...

Now, I'm interested in ways to standardize the GUI API.  In my
opinion, it would be useful if we could customize ximage and rview to
native OS conventions easily, perhaps by providing an OS specific
library.  It might also be useful to embed the core rendering tools in
a dynamic loading environment.  But, again, I don't know what it would
take.

-- 
Randolph Fritz
Eugene, Oregon, USA