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.
>
> If Kicad is going to rely on an external interpreter being installed
> to generate a usable BOM, the interpreter choice needs to be thought
> about carefully. I think I remember you saying that you wouldn't
> entertain python bindings (I appreciate we're not talking about
> bindings here) in Kicad until you could use python 3.x, is that right?
> also, does that mean that python 3.x would be a requirement of a Kicad
> install?
>   


Thanks Brian.  This is a good question.  I think we are talking about
40-100 lines of code in the actual script, no?

Those lines can be converted rather easily either way.  Do you not have
python 3 installed?  How hard would it be for you to install python 3? 
I have it installed, and use it for any scripts that I have written. 
How big of a problem is python 3 really?  When do you plan on starting
to use python 3?  When does Guido say python 3 is dead?  Do you think he
is going to stop working on it?

I never understood the hesitation.  Python 3 works fine for me, but am
prepared to write 40 lines of code in python 2.x *if you want*.


> If the only BOM output is an S-expression (or XML, or etc.) file, and
> anything else would be generated via an interpreted script I would
> regard an interpreter as a requirement of Kicad, and not just a "nice
> to have". 

> As a minimum, any Kicad install should be able to produce a
> human readable BOM output, which could be as simple as the standard
> .lst text file without relying on an external interpreter being
> installed.
>   

Does the intermediate XML file qualify as this?  XML is human readable.

What if you can load the XML file into excel or use xsltproc?  But if
you want to say an interpreter is required, it is not an unreasonable
point of view.


> The current dialog is a mess and I don't even know what works and what
> doesn't, it all seems a bit random. 

I've cleaned up what's behind it somewhat, but now want out of it to
something new.  I can commit what I've done, and start from a new menu
option I guess.  XML export or something like that.



> I am sure that anything you do
> will improve the situation and I'd be one happy customer with any
> improvement to BOM generation.
>
> Best Regards,
>
> Brian.
>
>