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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
