kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

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 <miguelangel@xxxxxxx> 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" <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("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" <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
> 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
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
>
>