kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

On 02/28/2017 05:20 PM, Wayne Stambaugh wrote:
[snip]
>>>> Regarding the second patch: I am looking for a way to store temporary
>>>> changes to libraries. Libraries are linked to files, and now the binding
>>>> is even stronger, as files are reloaded upon a change [1].
>>>>
>>>> It means that once I save only a part of modifications to a library, my
>>>> buffer will be reloaded and the remaining unsaved changes will be gone.
>>>> Do you think it is reasonable to disable cache updating when buffering
>>>> is enabled?
>>>
>>> I not sure I understand your question but the cache reloading doesn't
>>> make sense when copying libraries and creating the schematic cache
>>> library.  Otherwise, you get a library file write every new symbol you
>>> add to the library.  On a schematic with a 100 different symbols, this
>>> would be 100 file write operations just to save a library cache file.
>>> That is why I added buffering to the legacy I/O plugin.  I know it's an
>>> ugly hack but it's a stop gap measure until the new file format is in
>>> place which will eliminate the need for library caching.  I suppose we
>>> could change the cache reloading but that could have it's own set of
>>> issues.  Technically the cache should only be loaded when the cache
>>> hasn't been created, the library file name changes, or the file time
>>> stamp has changed since the last file load.  If the file is being
>>> reloaded other than these cases, then there is a bug in the cache
>>> loading logic.
>>
>> Actually I wanted to limit cache reloading even more: do not reload the
>> cache when a file timestamp changes & buffering is enabled.
> 
> That's fine but what happens if the file changes between the time it's
> opened and the time it's changes are written?  Any changes made to the
> file outside the current session are overwritten.  I know this is a rare
> case but it is always a possibility.  I suppose we could assume the risk
> and just overwrite any changes.

In either case we lose data. What I would like to have is: if you enable
buffering, then it means you do not care about the changes introduced in
another session. It is simply a library copy to be modified. Otherwise
every time the file is modified, the unsaved changes are gone from the
editor, and it would be a frequent case.

If you prefer, I can use a new property that leaves the current
principles as they are, and simply prevents reloading cache from disk.

>> In the new library manager, I am creating copies of modified libraries.
>> This way, one can select changes to be saved and drop the others.
> 
> You need to be careful here to make sure you refresh the schematic
> symbol links when you update the copy of the library that contains the
> schematic symbol links.

Good point. I assume using {Replace,Add,Remove}Part() is enough to
achieve the goal as they modify the library hash. I will conduct more
tests to be sure.

>> When a PART_LIB object is created, it is associated with a certain file.
>> If there are two PART_LIBs associated with the same file and one of them
>> has a new timestamp (i.e. editor saves *some* of the changes), the other
>> object will reload everything from the saved file in cacheLib() method,
>> losing all the unsaved changes.
>>
>> I want to inhibit cache updating when buffering is enabled. With the
>> proposed patch, it gets reloaded only if cache == NULL or if the file
>> name changed, but not when the file contents is changed.
> 
> This seems like a reasonable approach to the problem.  Please try to
> keep the library duplication code out of the plugin if possible.  I
> don't want the plugin interface to get overly complicated.  I already
> had to add code to the interface to support buffering which I would have
> rather not done.

Sure, I do my best to reduce the number of changes to the current
library/plugin interfaces. I am going to consult them with you before
proceeding.

>> If you see an easier solution, I will be grateful for details.
> 
> I wish I did.  Unfortunately the transition from the legacy format
> (linked symbols) to the new format (embedded symbols) is going to be an
> ugly and painful transition.  It's going to be worse than what we went
> through for the board file changes since footprints have always been
> embedded in the board files.  I don't see any elegant way to get from
> here the there bit I'm always open to suggestion.

As with many refactors - there is some pain involved, but usually the
end result is worth it.

Cheers,
Orson

>> Cheers,
>> Orson
>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> 1. https://git.launchpad.net/kicad/tree/eeschema/sch_legacy_plugin.cpp#n3359
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>>
>> _______________________________________________
>> 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: signature.asc
Description: OpenPGP digital signature