kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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
days.

> 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