Re: Long-term design goals for ePiX

[Andrew Hwang <ahwang@radius.holycross.edu>]

Andrew Hwang wrote:
> > One thing you might consider is exposing the ePiX internals via a
> > Python (or some such) interface so that it can be scripted rather than
> > written in C code. That solves the Windows problem, too (the Windows
> > user downloads the Python distribution and the ePiX pre-compiled DLL).
> >
> To clarify, do you mean having users' input files be scripts (in Python,
> say) and writing ePiX's picture object routines as library objects that
> can be called from a script?

Exactly. In Python:

    from epix import *

    bold()
    line((2,3), (3,5))

etc.

> > I'm thinking:
> >
> >            epix -Imyinclude -Lmylibs thefile.c
> >
> This is a nice idea! Three implementations come to mind:
> 1. Command line options (as you suggested)
> 2. A global config file (e.g. ~/.epixrc), or a specified config file
>   (epix -f ./config thefile.c)
> 3. An environment variable (EPIX_CFLAGS, say)
>
> as well as
> 4. Some combination of 1--3
>
> Any feeling about which would be easiest to use/least likely to cause
> problems in the future?

I would definitely argue against environment variables, as that space
is already terribly polluted, plus on Windows systems the setting of
these variables is arcane, fraught with "Out of environment space"
errors, and inconsistent between Win95/98 and NT.

Config files are not as bad, but they seem unnecessary in light of
command-line options.

Command-line options are my favorite because they work well in makefiles,
which is my preferred method for rendering a whole project's pictures
at once, and incrementally as needed (I'm too lazy to type "epix file.c"
and would rather just type "make")

BTW, there is a small oops in the epix.h file that prevents external
libraries. It's the declaration:

    int lines_printed = 0;

This prevents <epix.h> from being included in more than one file as the
linker complains about a multiply-defined symbol. This should be changed
to:

    extern int lines_printed;

and have the variable declared somewhere in the source. I made this change
manually and it works.

> > In my experience, the college or university is most interested in not
> > being exposed to liability, rather than profiting off copyright.
>
> I hope you're right, but fear the worst. :)
>
> The College has in many ways been reluctant to encourage the use of Free
> software, to put it mildly. However, our new president is trained as a
> computer scientist, and is well aware of the FSM, so one may hope for a
> gradual trickle-down of tolerance, if not enlightenment. Of course, use of
> Free software and supporting the development of Free software are not the
> same thing, but I was told by the Dean's office that having faculty
> publish software here (under *any* license) has no good precedent. Passing
> them the BSD disclaimer is a good idea, all the same.

I wish you good luck. If it helps, you can tell the Dean that publishing
as free software ensures wide distribution and acceptance, thus stimulating
further research and development. I, for example, would never have tried
ePiX if it wasn't free software.

-- 
Andrew Sterian                | <steriana@claymore.engineer.gvsu.edu>
Assistant Professor           | <http://claymore.engineer.gvsu.edu/~steriana>
Padnos School of Engineering  | (616) 771-6756
Grand Valley State University |