kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Hi Carl,


On 09/29/2013 02:38 PM, Carl Poirier wrote:
> Hi guys,
> 
> I'm almost there. I'm trying to get the library table done now but I have a few questions.

Actually it sounds like you succeeded on all fronts.  My comments below:


> 
> I built KiCad with:
> 
> KICAD_SCRIPTING ON
> KICAD_SCRIPTING_MODULES ON
> KICAD_SCRIPTING_WXPYTHON OFF
> FP_LIB_TABLE_SUPPORT ON
> 
> Got some warnings meanwhile:
> 
>     [ 64%] Swig source
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/pcbnew/../include/base_struct.h:749:
>     Warning 362: operator= ignored
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/pcbnew/class_drawsegment.h:70:
>     Warning 362: operator= ignored
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/pcbnew/io_mgr.h:440: Warning 325:
>     Nested class not currently supported (RELEASER ignored)
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/pcbnew/pcb_plot_params.h:40: Warning
>     401: Nothing known about base class 'PCB_PLOT_PARAMS_LEXER'. Ignored.
>     [ 64%] Generating pcbnew_wrap.cxx, pcbnew.py
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/pcbnew/../include/base_struct.h:749:
>     Warning 362: operator= ignored
>     class_drawsegment.h:70: Warning 362: operator= ignored
>     io_mgr.h:440: Warning 325: Nested class not currently supported (RELEASER ignored)
>     pcb_plot_params.h:40: Warning 401: Nothing known about base class
>     'PCB_PLOT_PARAMS_LEXER'. Ignored.
>     swig_import_helper fixed for
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/build/pcbnew/pcbnew.py
>     Scanning dependencies of target _pcbnew
>     [ 64%] Building CXX object pcbnew/CMakeFiles/_pcbnew.dir/scripting/pcbnewPYTHON_wrap.cxx.o
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/build/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
>     In function ‘void SWIG_InitializeModule(void*)’:
>     /home-local/capoi68.extra.nobkp/kicad/kicad_carl/build/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:142466:21:
>     warning: statement has no effect [-Wunused-value]


I get those same warnings.  SWIG can be hard to make happy, seems we've become content on
letting it whine.


> 
> Then I have made a small .sh script in <kicad_src>/scripts/ that converts all legacy
> modules to the pretty format. I have opened a few of them and compared with the legacy
> version. It seems good so far.
> 
> Then I am trying to get the library table in, but have some questions regarding the new
> dialog. First, the column order is not the same as what's generated by
> <kicad_src>/scripts/make_global_table.sh; the URI and type are inverted. Which one do we
> want?


S-expression elements in a fp_lib_table after (name) are order independent in the
FP_LIB_TABLE::Parse()-er.

The dialog establishes the correct column order.  The parser will take incorrect column
order OK, and is designed to allow changes of opinion.


> I can fix the wrong one. 

Fix the script then, thanks.

> Also, how am I supposed to get something in the Path
> segment column for the KISYSMOD environment variable? 

That table currently gets set only on entering the dialog.  I will look at this and see if
I can trigger another env-var fill after editing any lib path (uri).

The env-var table should be read only.  I am working on that today and will change it to
such.  This env-var table is just a reminder, not a tuning agent.


> If I define it in the terminal
> before starting pcbnew, it won't show in the dialog. 

It will show any environment variable referenced in a LIBPATH, if that env-var is in the
libpath at time of invoking the dialog (for now).  Only those environment variables
referenced in a libpath are shown.  This is done by using

  ${ENVVAR}

type syntax, i.e. wrapping a variable name in ${}.  If the env-var has also been set into
your environment, then its value will be shown in the table, else the value will be empty
and you cannot change it there after my fix today.


If I enter it in the cell in the
> dialog, in won't get saved. Finally, the "Options Editor" button doesn't do anything. Is
> it normal?

It is incomplete.   I plan on doing some of that work later today.

After 6 or 7 long years, 3.0 wx is about to be released this month or next.

(And since windows users are using 2.9 now (a.k.a 3.0 pre-release), I will probably use
the wxPropertyGrid for this options dialog.  Linux users may have to wait a couple of
months to use it, unless they build wx from source.  There is too much code there, and too
much value in wxPropertyGrid at first glance to consider duplicating that work.  I may
change my mind.)


> Besides that, I have tried writing the entire path by hand. I can then access the new
> libraries.


Well done Carl!  You did good.

The last step is to push to GITHUB.  I don't see a reason to wait, since the footprints
can live in several places at once.  The real question is when do we shut down the BZR
library repo, not when do we push to github.

At any time you can now re-run your script and get today's BZR onto your local disk,
incorporating the latest snapshot of the BZR library repo onto your local disk.

For now, you could make each *.pretty directory its own github repo, local to your work
environment.  Each should be a separate repo I think so that they end up being separate
repos on github.  This ensures maximum speed of the github plugin, library type "Github".
 Keeping the download zipfile under about 100kbytes will be prudent and appreciated later
by folks with less than supersonic internet speed.

Once you do that, you can then push each repo to a place on github, hopefully under a
common github user, and publish that base user location on this list.  Others can fork
your copies at any time in the future using github facilities, including somebody who
volunteers as the official maintainer/librarian.

We will soon need an official github librarian for the official kicad footprints.  This
will require somebody to volunteer for that responsibility.

One last word of caution about running the lib_convert.py script after you have created
local github repos in the *.pretty dirs:  remember that the lib_convert.py script deletes
the destination library before copying over.  This means that the script will delete your
*.pretty dir and the hidden .git directory, thus trashing your repo that you have
established in each *.pretty.  So you will have to find a way to work around that, at
least be aware of it.

This sort of incentivizes a clean move to github.com after you/we push, with a soon
discontinuation of bzr library.  I don't think the initial location of the github push is
that critical, since it is so easy to fork to a new location, the "final" location can be
different.

Also, even those not using github plugin can simply bring down the *.pretty dirs and use
them with the new fp table support using the "KiCad" plugin instead of the "Github" plugin
(library type).


Carl, you now have certain expertise that others on the list do not have.  We'll need you
near the front of the (footprint library) stage now, with a microphone in your back
pocket.  :)

Thanks for all your work,

Dick




> Carl
> 
> 
> 
> On Thu, Sep 26, 2013 at 3:41 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> wrote:
> 
> 
>     > I built KiCad a few times on Ubuntu and Arch, but never with python scripting.
>     >
>     > I will give this a try, ask if I have questions, and keep you updated of my progress.
> 
>     Thanks again.  To get kicad scripting build, here are some things from memory:
> 
>     install:
>       python-dev
>       swig
>       [maybe others]
> 
> 
>     use "ccmake ." (sic) in out of tree build directory to select
> 
>     KICAD_SCRIPTING ON
>     KICAD_SCRIPTING_MODULE ON  (probably not mandatory)
>     KICAD_SCRIPTING_WXPYTHON (mine is OFF, yours can be ON or OFF)
> 
> 
>     There is a script in <kicad_src>/scripts/make_global_table.sh
> 
>     This can be used as an example on how to automate the whole shebang.
> 
>     In fact, you can even have it generate your
> 
>        ~/fp-lib-table
> 
>     file by adjusting it to use "KiCad" plugin type, not "Legacy" and to teach it where your
>     *.pretty dirs are in the uri slots.
> 
>     Your *.sh script can call the python script with consistent arguments, and save you some
>     grief.  Then you can be a hero and we'd probably take your script into the project under
>     scripts/*.
> 
>     Thanks,
> 
>     Dick
> 
> 
> 
> 
>     >
>     >
>     > On Thu, Sep 26, 2013 at 12:25 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>
>     > <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>> wrote:
>     >
>     >     On 09/26/2013 11:14 AM, Dick Hollenbeck wrote:
>     >     > On 09/26/2013 10:52 AM, Carl Poirier wrote:
>     >     >> Hi Dick,
>     >     >>
>     >     >> I neither read the whole thread nor played with pretty yet, but if the steps
>     to convert
>     >     >> the libraries are fairly straightforward, I can volunteer to do it. I did however
>     >     create
>     >     >> many libraries in the old format so if needed, I will be able to validate the
>     >     conversion.
>     >     >>
>     >     >> If you agree, please write down the steps required for the conversion and I
>     will do it.
>     >     >
>     >     > Please tell me about your kicad environment:
>     >     >
>     >     > a) are you buiding your own?
>     >     >
>     >     > b) platform?
>     >     >
>     >     > c) have you built with python scripting yet?
>     >     >
>     >     > If c) is yes,
>     >
>     >
>     >     bzr co bzr+ssh://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/
>     <http://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/>
>     >     <http://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/>  legacy
>     >
>     >     To get all the libraries *as of today*, buy you maybe have already done this.
>     >
>     >     If so, then it is simply
>     >
>     >     $ cd legacy
>     >     $ bzr up
>     >
>     >     to get today's libraries.
>     >
>     >
>     >     > then try reading the instructions at the top of
>     >     >
>     >     >    <kicad_src>/scripts/lib_convert.py
>     >     >
>     >     > Me no python guru.
>     >     >
>     >     > Step 3) is the actual conversion.  The smd_dil would be replaced for each
>     library.  In
>     >     > this example there, smd_dil.pretty is actually a subdirectory.  The
>     *.kicad_mods will go
>     >     > into that directory.
>     >     >
>     >     > This suggests having a master directory above that, say called pretty_footprints
>     >     somewhere
>     >     > to stage this work.  In there you would generate a series of *.pretty dirs,
>     one for each
>     >     > library.
>     >     >
>     >     > Then build kicad with FP_LIB_TABLE support.  Create table rows in
>     >     >
>     >     >    pcbnew -> Preferences -> Library Tables.
>     >     >
>     >     > One row for each *.pretty directory.  This table can be copied to and from a
>     spreadsheet
>     >     > for editing.  Select a region, righ mouse click, paste into a spreadsheet.  Get it
>     >     right,
>     >     > copy it back.  The type should be "Kicad" for pretty libraries.  The Nickname
>     can be
>     >     > anything, typically the directory name without .pretty extension.
>     >     >
>     >     > Go into the module viewer, do some sampling, see your pretty footprints.
>      Establish
>     >     > confidence or talk of problems.
>     >     >
>     >     > Thank you.
>     >     >
>     >     >
>     >     >>
>     >     >> Carl Poirier
>     >     >>
>     >     >>
>     >     >> On Thu, Sep 26, 2013 at 10:39 AM, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>
>     >     <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>     >     >> <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx> <mailto:dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>>>> wrote:
>     >     >>
>     >     >>     I checked the size of our largest footprint library and when zipped it
>     scrunches to
>     >     >>     70kbytes.
>     >     >>
>     >     >>     This was not pretty, but legacy.  But I don't anticipate a noteworthy
>     >     difference in size.
>     >     >>
>     >     >>     Therefore the concept of getting 70kbytes in one https://github.com hit seems
>     >     reasonable
>     >     >>     even with country folks like me with slow internet access.  My internet speed
>     >     is only
>     >     >>     160bytes / second.  So the download time of this 70kbytes file, after it is
>     >     zipped and the
>     >     >>     https session is established, will be less than a second.  Maybe 1-3 seconds
>     >     total with
>     >     >>     SSL session establishment overhead, depending on github load and internet
>     whims.
>     >     >>
>     >     >>
>     >     >>     I am encouraged, and I think I will end up using this plugin as my main means
>     >     of getting
>     >     >>     footprints, period.
>     >     >>
>     >     >>
>     >     >>     If no one volunteers, I have it on my to do list to convert what we have to
>     >     pretty, then
>     >     >>     push it to github.  I would use lib_convert.py to do this, for each library.
>     >     >>
>     >     >>     If someone else wants to do it, that would be helpful.  I certainly
>     understand
>     >     the "show
>     >     >>     me" mentality.  If you've yet to see the GITHUB_PLUGIN work, then why
>     would you
>     >     invest
>     >     >>     time in this?  I understand that.  But I've also seen it work, so I am
>     >     confident that
>     >     >>     somebody will probably step up in the near future.
>     >     >>
>     >     >>     Just yesterday I made a tweak to the pretty output which tries to put pads on
>     >     one line if
>     >     >>     they are not tricked out with optional attributes.  That would be the
>     format to
>     >     use, from
>     >     >>     a build at least that new I suppose.
>     >     >>
>     >     >>     Also, note that a library repo can be pushed with a README.md file, and
>     in that
>     >     file you
>     >     >>     could elaborate on and include an index of all footprints in the library in
>     >     freeform text.
>     >     >>      This way a person could web-browse there and read about footprint choices
>     >     first, in
>     >     >>     potentially great detail.
>     >     >>
>     >     >>     Note that although subdirectories can be used in the repo, this view is
>     >     flattened as the
>     >     >>     plugin unzips the footprints into its cache.  So if you use subdirectories,
>     >     make sure you
>     >     >>     have unique footprint names.  With the upcoming options support, it will be
>     >     possible to
>     >     >>     build in directory filters or other tricks into the plugin.  But that will be
>     >     for some
>     >     >>     other developer to do.  I will provide the options support to all plugins.
>     >     >>
>     >     >>     Beyond that, there is also the ability to comment each footprint in the
>     >     *.kicad_mod file,
>     >     >>     manually using a text editor for now.  The *first* lines of
>     >     >>
>     >     >>     # ... anything
>     >     >>
>     >     >>     are ignored by pcbnew.  This may not be as helpful as the table of
>     contents in the
>     >     >>     README.md file.
>     >     >>
>     >     >>     You can sort of tell that this infrastructure is screaming for leadership.  I
>     >     don't see
>     >     >>     where that leadership needs to come from a programmer/developer.  It is
>     simple
>     >     >>     administration and guideline establishment.
>     >     >>
>     >     >>     But yes, it is still a little early, we've got to get it running on all the
>     >     platforms
>     >     >>     first.  Our thanks go to Brian, Miguel and anyone else helping with that.
>     >     >>
>     >     >>
>     >     >>     Dick
>     >     >>
>     >     >>
>     >     >>
>     >     >>     _______________________________________________
>     >     >>     Mailing list: https://launchpad.net/~kicad-developers
>     >     >>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >     >>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>     >     >>     Unsubscribe : https://launchpad.net/~kicad-developers
>     >     >>     More help   : https://help.launchpad.net/ListHelp
>     >     >>
>     >     >>
>     >     >
>     >
>     >
> 
>