← Back to team overview

kicad-developers team mailing list archive

Re: Plot and drill file generation via scripts


On Sun, May 05, 2013 at 10:09:59AM -0500, Dick Hollenbeck wrote:
> *) how many functions, say member functions, are there that operate on a BOARD, that need
> Clearly this is a small problem space.   However, the size is somewhat unknown, in as much
> as we don't know what will really be needed in the python top level interfaces yet.

Wasn't it tought to 'unificate' the action dispatching in general, not
only for python-able stuff? it would be good to have a better dispatch
mechanism (there is way too much stuff in the event handlers now IMHO)

> being used by every man, women and child on the planet, then even then you could probably
> set up a RAM disk on the server and still do it this same way just fine.

Exactly the same thing I said. Also I've already explained that a FILE*
clearly doesn't cut it. And on linux anyway /tmp is usually in RAM these

> Miguel's idea about extending the PLOT_CONTROLLER with some drill file generation
> functions makes the most sense to me, rather than doing a "DRILL_CONTROLLER".

Somewhat agree with that. The whole drill map is a plot after all so
maybe it could use some of the plot controller features. However the
drill generation options are completely different that the option for
plotting a layer. So, in the end, maybe a dedicated controller class
would be better. A nice thing would have to split the drill map code
into the plot controller and having the drill controller only generate
excellons and reports. That would need a not trivial amount of
refactoring (the common code for preparing the drill lists need to be
extracted and then called from both of the features); from a design view
it would be desiderable but I agree that's not an easy work to do.

> (BTW, StringIO is "file-like" only in a python duck typing sense.  The typemap cannot
> convert a StringIO object into a FILE*.)

Except on specific glibc implementation nothing can 'build' a FILE*
(that's mandated by the C standard AFAIK; a FILE* doesn't even need to
be dereferenceable to be valid! i.e. and implementation is free to use,
for example, some magic invalid address for stdin and stdout);
however a stream could be used in its place. Nothing would be gained
anyway, you need to wait the end of the plot and passing thru
the temporaries to have 'the stuff'.

Lorenzo Marcantonio
Logos Srl