kicad-developers team mailing list archive

[Miguel Angel Ajo <miguelangel@xxxxxxx>]

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" <miguelangel@xxxxxxx (mailto:miguelangel@xxxxxxx)> 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" <dick@xxxxxxxxxxx (mailto:dick@xxxxxxxxxxx)> 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@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> > > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > > More help   : https://help.launchpad.net/ListHelp
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help : https://help.launchpad.net/ListHelp
> > >  
> > >  
> > >  
> >  
> >