Responses inline...
> From: Georg Mischler <[email protected]>
> Subject: Re: [Radiance-dev] Meta files and library
> Date: May 12, 2016 12:58:14 AM PDT
>
> Am 2016-05-12 02:27, schrieb Gregory J. Ward:
>> The "graph files" are related to .cal files in an odd way.
>
> "Subtly incompatible" it is then...
> So a parser needs to use different patterns/escapes for seperating
> statements from each other. Apart from not seeing any of the simulation
> specific variables, is that the only difference?
Well, the .cal routines have their own set of runtime flags that determine
which features are supported. The bgraph program uses the default flags, which
are (E_VARIABLE | E_FUNCTION), so it doesn't support input channels as in
Radiance (although most users never see or use these).
Also, the syntax is similar but the interpretation is very different when the
variables match any of the standard ones ("keywords") such as "include", which
loads another file, and the many string variables like "title", "Blabel", etc.
The variables "?data" are also special with their own syntax, and load an array
of floating-point data that ends with a semicolon or EOF. So, quite a bit
different.
>> The pexpand command is called internally, as is psort by image
>> converters that want their vector primitives sorted.
>
> That would seem to make more sense as library routines then.
> Not sure if refactoring as such would be worth the effort now, though.
Yes, I suppose, although rholo also calls separate driver programs (in a
subdirectory of the executables), and rvu is capable of something similar.
>>> Since those tools are not used anywhere else, wouldn't it make sense to
>>> ditch $MLIB, and simply use $RAYPATH/meta instead?
>> Except that RAYPATH is a list of directories, where MDIR is a single
>> location. All the same, a function that finds the first meta
>> directory in $RAYPATH could be used instead.
>
> The new Python scripts do exactly that to find their "pyradlib" support
> library. Granted, that one has a more unique name (deliberately so),
> which is less likely to collide with something a user might have within
> their project.
Yeah. We should decide if it's worth the risk to change it.
>> Yeah, RIP many disused graphics output devices. We could remove the
>> references if anyone cares.
>
> If you have any interest in avoiding confusion among new users,
> you should care.
Of course I care -- I just wonder if anyone else looks at these man pages,
anymore. Easy enough to change.
>> The plotin tool converts from old-school plot primitives to metafile
>> equivalents. I don't know if anyone uses the original graph or plot
>> routines anymore, so this could probably be retired as well. The
>> functionality is better in bgraph, anyway.
>
> Ah, so "plot files" are indeed something different from "graph files".
> Since the plot(5) man page presumably documenting that format is gone,
> keeping a program around that depends on it doesn't make much sense.
Well, it was never my package, so I've no idea if it's still "out there,"
somewhere. Used to be standard on BSD Unix, anyway. Anyone else know what
we're talking about?
-Greg
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
