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" <[email protected]
> (mailto:[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 (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" <[email protected]
> > > (mailto:[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]
> > > > (mailto:[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]
> > > (mailto:[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
