kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/29/2010 08:22 AM, Brian Sidebotham wrote:
> On 29 July 2010 06:39, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>   
>> I have spent most of the day in eeschema's BOM support code.
>>
>> One idea I have is to simplify that code significantly, because of a
>> belief that we will be unable to meet all needs in C++.  It will take a
>> user modifying a script for him to get truly what he wants.  Using a
>> script means it requires no compiler or build environment.  For example,
>> a python script.
>>
>> To embellish this idea:
>>
>> When he clicks the BOM button, we export everything we (would ever) need
>> to an S-expression file, with basically NO options since everything is
>> exported.  Then transparently we run an external script/executable which
>> can do anything, but would be passed the name of the S-expression file,
>> and perhaps a desired final output filename that might be CSV.  The
>> script converts the S-expr file to CSV or whatever, maybe emails it to
>> grandma.
>>
>> For a configuration dialog, the user only gets to name the
>> script/executable that is run on the exported file, perhaps the name of
>> the final file, and basically nothing else.
>>
>> I write 3 or 4 python scripts which duplicate what we have now in terms
>> of outputs.  But the 3rd one is better, the single line per part type,
>> which is the one I am most interested in, in CSV output format, with
>> full field name support.  These scripts go into <bin-install-dir>/scripts/*
>>
>>
>> I think I can load S-expressions now into python.  With this plan a
>> python install becomes a nice to have, but not a true Kicad
>> *requirement* since the user can provide his own executable/script in
>> any language, including Java, SCALA, or C++, or not run the BOM generator.
>>
>>
>> (BTW, I have worked with Groovy extensively and was disappointed with
>> the lack of compile time type checking.  SCALA looks better in some
>> ways, and has many concepts in common with Groovy.  I do not really know
>> it yet.  It runs on top of the JVM like Groovy. At first glance it looks
>> interesting for anyone currently working in Java.  You can actually
>> write scripts in it too.)
>>
>>
>> This is one thing that could be done to the BOM generator.  I don't like
>> the current dialog window there at all, and am not too exciting about
>> fixing something for which I have no enthusiasm for.  I am not sure it
>> is worth salvaging.  A few lines of python code will do a better job and
>> give the user the ability to easily refine the output him/her-self.
>>
>> What do people think?
>>
>> Dick
>>     
> Hi Dick,
>
> A script may not need a compiler or build environment, but it does
> require an interpreter. Python is my interpreter of choice for
> scripting. I like python so much it tends to pain me to write some
> code in other languages when I know how easy it would be to do in
> python.
>   

Brian,

Are you interested in writing the 3 scripts?  I would gladly defer to
your python prowess on this for initial coding.  We can then keep the
door open to refinement thereafter, no?

I can send you a hand made XML file while I go to work on the export to
actually be able to create such a file.  We can work in parallel.

Are you game?

Dick