Before I propose any refactoring on the drill or plot code, I'm writing tests for the current drill or plot code. I'll lose all goodwill from the Kicad team if I end up breaking someone's gerbers...
I need to finish my Maker Faire demo, but expect a full test suite for the drill and plot code near the end of May, maybe earlier if I get my demo done before the last minute or if I need to procrastinate from working on my demo. Adam Wolf Wayne and Layne, LLC On Fri, May 3, 2013 at 10:31 AM, Miguel Angel Ajo <[email protected]> wrote: > 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 > +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" <[email protected]> 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("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 > +34911407752 > 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" <[email protected]> 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 : [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 > > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
