kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Lorenzo,

When I said file-like object, I was speaking in a Python context.  In
Python, a file like object supports seek() and other things you do on
files.  That's why I mentioned StringIO--it's a helper class to treat
strings like file-like objects.  I believe this mitigates all your
complaints about non-linear writes.

I don't know if you understood what Miguel and I were saying.  I
already bound FILE * to python file-like objects.  That's in this
patch.

I'm not worried about the performance of the board plotter at all. I
think that files aren't always the best IPC method.

Adam Wolf
Wayne and Layne, LLC

On Fri, May 3, 2013 at 1:09 PM, Lorenzo Marcantonio
<l.marcantonio@xxxxxxxxxxxx> wrote:
> On Fri, May 03, 2013 at 10:27:12AM -0500, Adam Wolf wrote:
>> Because the call that opens the file doesn't know anything about what layer
>> you're on, there's no way for the PLOT CONTROLLER to honor your "Use Gerber
>> Extension" option.  Because there's logic in the dialog box, PLOT
>
> That's by design. You can plot *more* than one layer on a plot, so you
> can't tell what layer are you on (for example I do a layout pdf with
> both silks, masks, pastes, pcb edges *and* the sheet border: what would
> be the layer for this plot?); however an entry point for computing the
> 'usual' file names could be useful: it should be already *somewhere*
> (GetGerberExtension, which is static), need to be more accessible from
> the plotcontroller maybe. Also for some people both the default layer
> filenames and the 'gerber extension' (which are somewhat arbitrary since
> every cad use its set) are not the right ones. Example: our express
> fabricator wants the board cuts with extension .gko, drills with
> extension .dri (instead of drill) and drill reports with extension .tol
> (in fact they want a slightly different format for the drill report).
> And the file name must be the 'item code' (they assign it).  In other
> words the 'gerber extension' feature (while useful) is arbitrary and
> definitely not universal.
>
> You have python (which is turing-complete) so you can compute correctly
> whatever name you need. Exporting the function to build the name however
> is a good idea (GetGerberExtension, and BuildPlotFileName essentially).
> However there could be a better python (system) routine for handling
> filenames than the last one (scripting languages tend to be rich in
> pathname handling).
>
>> If we have part of the API take in open file-like objects, then we get a
>> bunch of fun things on the Python side.  We can pass in StringIO, so we
>> could generate these files and squirt them out a socket without a temp file
>> on disk.  We could write directly into a compressed file, or any number of
>> other things.
>>
>> Thoughts?
>
> File-like objects are not enough, sorry... plotting is not always like
> writing a sequential file.
>
> Can't do that for PDFs, since they are processed in multiple steps and
> need random access (I don't remember if the compression is done in core
> now or still need a temporary file).
>
> Can't do that for gerbers either since you need to declare apertures at
> the beginning (so the file is rewind and rewrote with the aperture table
> during plot close).
>
> Also, can you bind these 'objects' to FILE* or something like that without
> breaking pcbnew? (some wxStreamStuff, maybe...)
>
> Remember that for now python is an optional feature, not a requirement.
>
> So: for filenames 'tools' could be added for aiding in generating the
> 'correct' one; the completed plot file is ready *only* when the plot is
> closed, so no pipelining for you, sorry. In fact you could even redesign the
> interface to take the file name at close time, for some plotters..
>
> With a huge work everything could be changed to build the file in core
> and then write/return it as string, but does it really matters? Often the
> /tmp storage is in ramdisk anyway and these file should fit completely
> in the filesystem cache, so I don't think that using a scratch file
> would be so bad. You could even mmap it at the end (is this worth the
> trouble?)
>
> One last thing. Are you really worried about performance of the board
> plotter? It's not one of the thing you use every second....
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp