kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey Nick,

On 01/06/2018 07:40 AM, Nick Østergaard wrote:
> 
> Den 6. jan. 2018 1.08 AM skrev "Wayne Stambaugh" <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>>:
> 
>     Hi Matthijs,
> 
>     On 01/03/2018 02:40 AM, Matthijs Kooijman wrote:
>     > Hi Wayne,
>     >
>     > I just tried the remapping tool as well, and wanted to share some
>     > thoughts on it. This e-mail, where you're explaining how the remapping
>     > process works seemed like an appropriate place to reply.
>     >
>     > I tested this two weeks ago, using the 2017-12-22 <tel:2017-12-22>
>     daily build ppa, but
>     > didn't get around to writing up my experiences until now.
>     >
>     > Remapping of most of the symbols in my project failed. I couldn't
>     quite
>     > reproduce what was failing (and in my reproduction attempts, I think I
>     > overwrote the .pro file backup, so can't start from scratch), but I
>     > think the problem was that I used to have /usr/share/kicad/library
>     as a
>     > symlink, but added the libraries using their canonical path to the
>     > library table. I realize that there was a recent fix for this, but
>     I had
>     > that fix included (looking at the build date). I suspect that fix only
>     > works when the actual file is a symlink, not when a directory
>     further up
>     > the hierarchy is a symlink, but I didn't actually test this.
> 
>     The symlink issue has been fixed so duplicate libraries will not show up
>     in the project symbol library table with different nicknames.
> 
>     >
>     >> The remapping will not look up by symbol name in the symbol library
>     >> table if the symbol is not found in the original library in the old
>     >> library list that it was loaded from.
>     > I was quite surprised that this didn't happen. In particular, the
>     > remapping tool said it couldn't find some symbols, while they were
>     > certainly available in the list of libraries I configured. I did not
>     > understand why it would not find them.
>     >
>     > The procedure implemented now (find the symbol in the old list first)
>     > totally makes sense. However, I would think that *if* this procedure
>     > fails, looking up the symbol by name in the new list could be a good
>     > fallback?
> 
>     Doing this would completely defeat the purpose of the symbol library
>     table and reintroduce the bug that has existed since the beginning of
>     the project.  Symbols are now required to be mapped to a specific
>     library.  No more searching through the list of libraries and hoping
>     that the first instance of a symbol is the correct one.  If the
>     remapping algorithm cannot find the exact library match which is
>     currently being used (and should be in the project library list or the
>     cache) to provide the symbol, then there is no way to determine the
>     correct library and therefore cannot be remapped.  It also means that
>     your schematic is already broken.  This is why you should not skip the
>     rescue feature.
> 
>     >
>     > As I said before, I can't quite figure out what the problem was
>     for me,
>     > but I can imagine various ways where library layouts, or library
>     > locations change. Especially considering that a project is only
>     remapped
>     > when it is opened, it might be that we'll be remapping projects years
>     > after the upgrade to v5, or maybe we'll be remaping projects published
>     > by others, in both cases it seems likely that libraries live in
>     > different places. Would it not make sense to do a best-effort matching
>     > in this case, instead of just not remapping the symbols?
> 
>     This should not matter.  As long as the cache library is correct, then
>     the rescuer can create a rescue library which will contain the correct
>     symbols.  If you cache library is invalid, then you schematic is already
>     broken because the rescuer cannot rescue symbols that do not exist in
>     the cache library.  The remapper should have no issues when the rescue
>     is performed correctly.  I will repeat, do *not* cancel the rescue or
>     you are likely going to have issues.  I am going to add a dry run
>     feature but it's not going to be as dry as I would like it to be.  In
>     order to do this, the rescue library must be generated which changes the
>     existing rescue library if it exists and changes the project library
>     list if it doesn't.  That means at a minimum I will have to back up
>     those files and restore them at the end of a dry run which is risky but
>     I cannot think of a better way to handle this.
> 
> 
> Is it not possible to just keep this new rescue library in memory
> instead of storing it on disk?

I'm not sure that you could add a file saved in memory to the project
library list.  The list itself can be stored in memory without updating
the project file.  The rescue library must be available in the project
library list in order for the remapping to be successful.

> 
> 
>     >
>     >
>     > Some extra confusion rose from the fact that, even though the symbols
>     > failed to remap, they were still shown properly. Only when opening the
>     > schematic a second time after remapping, the symbols were shown as
>     > question marks. I suspect that directly after remapping, eeschema
>     still
>     > had the original libraries loaded, which were removed from the project
>     > file the second time. Would it make sense to actually unload the old
>     > libraries after remapping (if this is indeed what happens)?
> 
>     This is the cache at work which works until the schematic is saved.
>     Once the cache is rebuilt using the symbol library table, any symbols
>     that did not get remapped will have broken links.  I'm not sure what the
>     best solution is here so I may have to rethink this particular behavior.
>      Regenerating the cache library before saving the schematic is risky and
>     somewhat atypical but that may be a solution to this issue.
> 
>     >
>     >> Look for the library by path and full file name in the global symbol
>     >> library table.  If the library cannot be found in the global symbol
>     >> library table and the file exists, add this library to the project
>     >> symbol library table and give it a unique name if necessary.
>     > Is this last part implemented already? I couldn't find any
>     reference in
>     > the code when I looked, and I *think* my setup should have triggered
>     > adding new libraries instead of failing to remap.
> 
>     Yes, it exists in eeschema/dialogs/dialog_symbol_remap.cpp.
> 
>     >
>     > Gr.
>     >
>     > Matthijs
>     >
>     >
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     > More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
>     >
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
> 
>