kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 29 July 2010 14:44, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 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 don't have Python 3 installed. If it can install alongside 2.x then
that would be fine, but I am not sure it can be installed in parallel.
I have several apps written in python which are written to be
compatible with 2.4

The reason for that? The CentOS box they are deployed on has 2.4 in
the repository. It works and is stable and is a standard CentOS
deployment.

Some of the development of those apps is done on the same PC as Kicad
is installed and used.

> 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*.
>

I am not against python 3, which perhaps is what you may have summised
from my previous mail. I have been burnt by python versions though.
Two people in the same office space developing code in python. One
(Fedora) box has 2.6 installed, and one (CentOS) box has 2.4
installed. The result was incompatible code between boxes, the CentOS
2.4 python didn't have the new string formatting that was introduced
with 2.6. Lesson learnt.

>> 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.

I think that you cannot print an XML file and then stuff components
whilst reading it. So I don't think an XML would qualify.

> 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.

I think having to use an external interpreter for a standard user just
to get a basic BOM output is a tall order.

>
>> 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.

Perhaps it does require a new menu option instead, and just leave the
current GUI pretty much as-is.

I would really like a verbose output that can then be transformed
neatly in a script. I'd certainly make good use of this feature!

Best Regards,

Brian.