I like your idea Adam, specially because you can change file for a stringio, and it could work..
Lorenzo, what do you think?, do you like Adam refactor idea for the plot controller? I think it's important that we have similar interfaces at both sides, and also that we have a drill controller (hehe, my implicit meaning was more for Adam that for you) but if it's good if anyone gets it done. Cheers! :) Miguel Angel Ajo http://www.nbee.es (http://www.nbee.es/) +34911407752 skype: ajoajoajo On Friday, 3 de May de 2013 at 17:27, Adam Wolf wrote: > I agree that the plot and drill generation could have a similar API. > However, if I'm going to put time into the Kicad C++ half, I want to improve > PLOT CONTROLLER. > 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 CONTROLLER > doesn't use the same code paths as someone generating files from the UI. I'm > not convinced we want the plotting logic to open and close files. I'm > running into serious issues in the Python side with the plotting half when > doing things like "open a board file with this relative path and drop the > plot files into this relative path". With the drill half, this works fine, > because I can give the drill calls any open file-like object. > 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? > Adam Wolf > Wayne and Layne, LLC > On May 3, 2013 3:07 AM, "Miguel Angel Ajo" <miguelan...@nbee.es > (mailto:miguelan...@nbee.es)> wrote: > > Hi Adam, > > > > I'm rereading your work, and It's something we all love to have, but, I > > have a concern: > > > > Plot controller, works in some way (thanks to lorenzo abstraction) > > different to the drill. > > > > With the plot controller you just open a plot controller, tell it the > > format and filename, etc… > > set the options, and plot. > > > > For the drill, using your current implementation, you need to open a > > file and pass it to the > > driller. > > > > f = open(path, "w") > > > > > > logger.info (http://logger.info)("Writing drill file.") > > > > > > hole_count = excellon_writer.CreateDrillFile( f ); > > > > > > > > the python file get's converted to a FILE* thanks you your swig in typemap > > > > I suppose you did it this way to use the current implementations as is, > > without > > big modifications, thus reducing pain by touching other peoples code. But, > > wouldn't it make more sense to: > > > > > > 1) get it working in the PLOT_CONTROLLER: but, ok, it's not exactly a > > plot.. > > 2) Else, make a DRILL_CONTROLLER, with just one format (that's ok) and > > then > > with time we can provide all the other drill formats thru the same > > interface? > > > > > > Then we could hide in the DRILL_CONTROLLER all the looping , and we > > could just > > provide a generate_drill_file, with layer1,layer2, filename… > > > > > > What do you think about it?, if you like the idea, can you yet invest a > > few extra hours > > to get it refactored this way? > > > > PS: > > I'm just worried of providing a python interface one day, and then > > changing it > > again a few months later and breaking everybody's scripts. :) > > > > > > > > Miguel Angel Ajo > > http://www.nbee.es (http://www.nbee.es/) > > +34911407752 (tel:%2B34911407752) > > skype: ajoajoajo > > > > > > On Thursday, 2 de May de 2013 at 19:55, Adam Wolf wrote: > > > > > Hi Dick, > > > Thanks. Let me know if there's anything I can do to help get this or > > > similar functionality built-in. Wayne and Layne volunteers to do any > > > desired refactoring to drill/plotting in order to reduce logic in the > > > dialogs and create a solid and small API. If this is something you want, > > > please note I am not an expert at C++, however, so I would greatly > > > appreciate an outline in order to increase the chances that the branch > > > will eventually be integrated. > > > I can't do much more with this functionality until after Maker Faire, so > > > May 20th or so, but I can answer emails and continue to test the Python > > > scripts. > > > Adam Wolf > > > Wayne and Layne, LLC > > > On May 2, 2013 12:46 PM, "Dick Hollenbeck" <d...@softplc.com > > > (mailto:d...@softplc.com)> wrote: > > > > On 05/01/2013 09:39 AM, Adam Wolf wrote: > > > > > Hi folks, > > > > > > > > > > One of the tasks I've been doing for Wayne and Layne for Kicad is > > > > > command line plot and drill generation. Internally, we're going to > > > > > use it to generate files upon commit to better track progress in the > > > > > distributed team, but externally, we're working with a friend of ours > > > > > who runs a PCB order service. He usually takes gerbers and drill > > > > > files, but through his web interface, you can upload Eagle files and > > > > > it'll "do the right thing" and show you an automatic preview and > > > > > everything. We're trying to let him do the same for Kicad. > > > > > > > > > > This required a few changes, and we've made what we think is the > > > > > minimal set of changes in Kicad to do this. > > > > > > > > > > The patch is attached, and we believe it matches coding standards. > > > > > It's based off of r4123 from last night. > > > > > > > > > > Quickly highlighting the changes we made: > > > > > > > > > > * Added a few files to the scripting interface and a typemap so FILE > > > > > * in C++ turns into file objects in Python > > > > > * Moved GetGerberExtension to common_plot_functions.cpp. I tried > > > > > just exporting the plot file it was in, and had some issues. > > > > > * I moved the fclose outside of CreateDrillFile in > > > > > gendrill_Excellon_writer.cpp. > > > > > This was causing issues in Python. I added an fclose after each time > > > > > CreateDrillFile was called. You pass in a file handle, so I think > > > > > this is > > > > > probably ok. > > > > > * Overloaded PLOT_CONTROLLER::OpenPlotfile so it will take a file > > > > > extension. > > > > > > > > > > Future work: > > > > > * There is a good amount of logic in the dialogs, for both plotting > > > > > and drill file generation. Because of this, I had to redo some logic > > > > > in the Python program. While there is more testing to be done before > > > > > I hand this off to the PCB order service, I'd like to minimize the > > > > > logic in python for this--if something changes in Kicad regarding > > > > > these files, like the recent NPTH/TH two file drill generation, I > > > > > would prefer the Python script to automatically "do the right thing". > > > > > However, I'm comfortable maintaining these scripts and watching for > > > > > regressions with each build--the Wayne and Layne build cluster already > > > > > does this for the Kicad packages. > > > > > * The scripts are not complete. Right now, they're mostly untested, > > > > > but they prove out the concept. Some of the arguments are > > > > > unintuitive. > > > > > If you use the scripts provided, and they explode your computer, > > > > > I told you so. If there isn't serious pushback to the concept, I'll > > > > > polish > > > > > the scripts up over the next few days and release them along with > > > > > their tests. > > > > > > > > > > Please let me know if there's anything I can do to help this along. > > > > > > > > > > What do you think folks? > > > > > > > > > > > > Adam, > > > > > > > > Thanks for your contributions to KiCad. > > > > > > > > Sorry I have not had time to look at this, but it is something of > > > > interest to me, just > > > > need some time. > > > > > > > > There is something about having scripts that, at least in theory, > > > > suggest being able to > > > > achieve a certain amount of consistency across runs. > > > > > > > > Dick > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mailing list: https://launchpad.net/~kicad-developers > > > > Post to : kicad-developers@lists.launchpad.net > > > > (mailto:kicad-developers@lists.launchpad.net) > > > > Unsubscribe : https://launchpad.net/~kicad-developers > > > > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~kicad-developers > > > Post to : kicad-developers@lists.launchpad.net > > > (mailto:kicad-developers@lists.launchpad.net) > > > Unsubscribe : https://launchpad.net/~kicad-developers > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp