On 1/10/2018 5:46 AM, Matthijs Kooijman wrote: > Hi Wayne, > >> The symlink issue has been fixed so duplicate libraries will not show up >> in the project symbol library table with different nicknames. > I noticed some issues with my previous build (2017-12-22), but using the > 2018-01-03 build, symlinks (both in the directory and filename) indeed > seem to be handled correctly. > >>> 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. > I'm not suggesting to do this all the time, only during remapping. So at > that time, the library list is the old one, and is still subject to > this ambiguity bug anyway. Also, I'm suggesting to *only* do this if the > remapping otherwise fails, so this would just be a best-effort guess. > Better to have most of these symbols right, then all of them unmapped? > AFAIU any mismappings would also be identified by the subsequent rescue > dialog and pointed out to the user.
We can agree to disagree on this point. I will not add code that reintroduces a bug that I just spent a lot of time fixing. > >> 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. > I can't quite remember if I skipped the rescue dialog (quite possibly), > but I can imagine a user (such as me) would reason that there is no need > for rescueing symbols into a rescue library, since all symbols are > available in their newly set lib table. The symbols in your legacy schematic are almost certainly not in the new symbol library table given the recent changes to the symbol libraries. They are in your old symbols libraries if you haven't updated them or in your project cache library. Rescuing symbols from the cache is required to ensure that same symbols that you used to design the schematic. Maybe we didn't place enough emphasis on how dire not rescuing your project is. It means that a symbol in your schematic is no longer available in it's current form anywhere but the cache library which is temporary and is overwritten every time the schematic is saved. If that doesn't scare you, than nothing will. > > Specifically: If my symbols are not available in the old-style library > list, but are available in the new-style library table, I can see three > outcomes: > 1. If I perform a rescue, I get all symbols remapped to the rescue lib. This is false. If the cache is corrupt or the symbol cannot be found in any of the libraries in the project library list, there is no way to remap it. If you don't think the cache cannot be corrupt, we have had users who were using vcs and not including the cash library which cause the cache to be out of sync with the schematic when they reverted changes to the schematic. The moral of the story, treat your cache library like gold. > 2. If I cancel the rescue, all symbols are unmapped. This is false. As long as the symbol can be found in a library in the project library list (not the symbol library table) it will get remapped. If a symbol has changed since it was placed in the schematic, it may break the schematic depending on the change. This is why you should always rescue. > 3. If I cancel the resecue and my fallback-guessing suggestion is > implemented, most of my symbols will be mapped correctly (and > possibly some will be incorrect). This is false. There is no guarantee that any of the symbols will be correct or even found by searching through the symbol library table. > > As a user, I would prefer outcome #3 over the other two. To fix my > schematic from outcome #1 and #2, I will have to manually fix up all > involved symbols to point to the right library again (having them point > into the rescue library makes the schematic work, but is not preferred > when the symbols are available in the symbols). > >>> [ About code that adds missing old-style libraries to the project >> sym-table] >> Yes, it exists in eeschema/dialogs/dialog_symbol_remap.cpp. > > Ah, I expected this to happen only for libraries containing remapped > symbols, but I see now it happens for all libraries in the schematic, > which makes sense. Thanks. > > > > A related question: How are the changes in library layout intended to be > handled, when combined with the remapping dialog? AFAIU the migration to > the new kicad-symbols repository also involves renaming a lot of > libraries (e.g. Connectors.lib -> Connectors_Generic.lib). If you > upgrade to this new library layout, the (v4) library list must also be > updated to match the new library names? Or is there some automatic > conversion for this? > > When you're still running v4, this can be fixed by manually fixing the > library list with the new library names. But when running v5, the > library list can (AFAICS) no longer be edited, but it is also assumed to > be correct by the remap dialog (which it will not be, then). Or am I > missing something here? > > This would also be a case where the fallback I suggested above could be > helpful, though I guess a more reliable method would be better here. > > Gr. > > Matthijs > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
