kicad-developers team mailing list archive

[Diego Herranz <diegoherranz@xxxxxxxxxxxxxxxx>]

Please ignore the previous attachments. They should have been these.

Thanks.

On Sun, Nov 26, 2017 at 10:55 AM, Diego Herranz <
diegoherranz@xxxxxxxxxxxxxxxx> wrote:

> Hi, Nick
>
> Changes like: (- is removed, + added)
>
> -Wire Wire Line
> - 12550 700  12600 700
>
> -Wire Wire Line
> - 12700 700  12700 700
>
>  Wire Wire Line
> - 22250 14500 22250 11600
> + 22250 9200 22250 14600
>
> - Wire Wire Line
> - 22250 9200 22250 14600
>
> - Wire Wire Line
> - 22700 750  15350 750
>
>  Wire Wire Line
> - 16650 750  16650 750
> + 15350 750  22700 750
>
>
> This happens on a dummy schematic which I've got for basically trying
> things out in KiCad, and to test nightlies. So the schematic is basically a
> mess.
>
> Thant means I've got crappy connections (before.png), which the rescue
> process broke (after.png). Maybe it wouldn't have happened if the
> connections were nice in the first place, but I wasn't expecting them to
> break.
>
> Thanks!
>
>
>
> On Sat, Nov 25, 2017 at 9:15 PM, Nick Østergaard <oe.nick@xxxxxxxxx>
> wrote:
>
>> What modifications are made to the wires?
>>
>> 2017-11-25 21:28 GMT+01:00 Diego Herranz <diegoherranz@xxxxxxxxxxxxxxxx>:
>>
>>> Hi,
>>>
>>> Related to this, I'm migrating an old design (~2 month old nightly) to
>>> the current master. First I faced some problem with '/' characters (
>>> https://lists.launchpad.net/kicad-developers/msg31705.html) but there
>>> have been some improvements since then so I'm trying again.
>>>
>>> When opening the schematic, 2 dialogs are shown:
>>> 1) Rescue symbols dialog: it offers to rescue a couple of symbols which
>>> use '/' in their name. It seems to rescue them properly on xxxx-rescue.lib
>>> (replacing '/' by '_')
>>> 2) Remap dialog: Everything gets remapped properly except the symbols
>>> mentioned in 1). That is because xxxx-rescue.lib is not in sym-lib-table
>>> yet. After adding it to sym-lib-table, I can edit those broken symbols
>>> ("?")  to point those rescued in xxxx-rescue.lib and it all looks OK.
>>>
>>> After this, which I think that can be challenging for many people (it
>>> has been for me), it seems everything should be OK now. However when I push
>>> the netlist to pcbnew, it shows a few changes and I wasn't expecting any.
>>> Comparing the schematic file with a text editor a few wires have been
>>> modified.
>>>
>>> I've don't some testing it seems the wires get modified when doing 1).
>>> If I skip the rescue, no wire gets modified.
>>>
>>> Why is that happening? I wouldn't expect the rescue process to modify
>>> wires. Am I doing something wrong?
>>>
>>> Many thanks,
>>> Diego
>>>
>>>
>>>
>>> On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
>>> wrote:
>>>
>>>> On 11/24/2017 05:01 PM, hauptmech wrote:
>>>> > On 25/11/17 02:14, Wayne Stambaugh wrote:
>>>> >> This is *the* fatal flaw with the cache library.  User's assume it is
>>>> >> stale symbols or a temporary copy.  It is not.  It is a snapshot of
>>>> the
>>>> >> current library symbols linked to the symbols in the schematic.  It
>>>> gets
>>>> >> refreshed every time the schematic is saved.  Once you delete this
>>>> file
>>>> >> or keep an out of date copy using cvs, all bets are off.  It is only
>>>> a
>>>> >> matter of time before one of your symbol libraries changes or gets
>>>> >> removed and you will end up with a broken schematic.  The rescue code
>>>> >> depends on the cache being up to date in order preserve you
>>>> schematic.
>>>> >> If the cache is not current, the rescuing cannot be guaranteed.
>>>> >
>>>> > I don't think it's necessarily a flaw. And your description above is
>>>> > indeed a cache. That's not a bad thing. I recall that I left it out of
>>>> > version control because I wanted to make sure fixes to my symbols were
>>>> > always propagated to the design. In the repo I'm referencing for this
>>>> > discussion I had 10 project files all using the same local library. I
>>>> > didn't want to have to manually update each schematic to propagate
>>>> > changes. Deleting untracked files was what I did instead. At the time
>>>> no
>>>> > one was making breaking changes to system installed symbols, so the
>>>> > system libs were stable for this workflow.
>>>> >
>>>> > I'm trying think of the least effort way to migrate an old design in
>>>> > these circumstances.
>>>> >
>>>> > Can we have the rescue code fail if no cache file is found? That at
>>>> > least lets the user know they are in uncharted territory. Then if a
>>>> lot
>>>> > of users come complaining you will know if it is worth doing a bit
>>>> more
>>>> > in the rescue code.
>>>> >
>>>> > If the cache is not available during rescue you can load a copy of the
>>>> > libraries that were current at the schematic save date and either
>>>> > re-cache them or rescue them directly. But this is only worth doing
>>>> if a
>>>> > significant number of users are affected.
>>>>
>>>> AFAIK, the rescue code doesn't do anything if there is not cache file
>>>> because the cache file is used for the comparison.  I actually
>>>> considered adding a check on schematic load to warn the user with a list
>>>> of all of symbols linked to the cache library so they could fix them.
>>>> I'm not sure this is desirable but at least users would know that
>>>> symbols were missing from their libraries and the links were falling
>>>> back to the cache which is tenuous at best.
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>

Attachment: after.png
Description: PNG image

Attachment: before.png
Description: PNG image