In addition to the issues described earlier, I filed a bug in parallel
about kicad freezing after closing pcbnew where fpinfo-cache writing to
network locations would take 10s (not a network speed issue).
https://bugs.launchpad.net/kicad/+bug/1838209
Global cache should not be written everytime
On 2019-07-24 13:58, Andy Peters wrote:
On Jul 23, 2019, at 2:46 PM, Jeff Young wrote:
Hi Kevin,
No this is just a cache of footprint library properties so that we can
index and search footprints without loading them all into memory.
It’s entirely for performance.
User question:
Should
> On Jul 23, 2019, at 2:46 PM, Jeff Young wrote:
>
> Hi Kevin,
>
> No this is just a cache of footprint library properties so that we can index
> and search footprints without loading them all into memory. It’s entirely
> for performance.
User question:
Should the project-level cache file
Hi Kevin,
No this is just a cache of footprint library properties so that we can index
and search footprints without loading them all into memory. It’s entirely for
performance.
Cheers,
Jeff.
> On 23 Jul 2019, at 15:35, Kevin Cozens wrote:
>
> On 2019-07-23 11:47 a.m., Seth Hillbrand
On 2019-07-23 11:47 a.m., Seth Hillbrand wrote:
Could we write the global cache in the user's config directory next to where
we write fp-lib-table?
If we cache global, we might not need project-based caching.
I'm not clear whether you are talking about caches of what items are
available or
On 7/23/19 2:28 PM, jp charras wrote:
> Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
>> On 2019-07-23 13:38, jp charras wrote:
>>> Le 23/07/2019 à 19:22, Jeff Young a écrit :
Hi Seth,
I think that would work. And you’re right — there probably aren’t
enough project libs to
And come to think of it, there is Murphy’s Law:
The best way to ensure that someone out there has hundreds of local libs is to
get rid of the local-lib-cache.
Cheers,
Jeff.
> On 23 Jul 2019, at 12:28, jp charras wrote:
>
> Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
>> On 2019-07-23
Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
> On 2019-07-23 13:38, jp charras wrote:
>> Le 23/07/2019 à 19:22, Jeff Young a écrit :
>>> Hi Seth,
>>>
>>> I think that would work. And you’re right — there probably aren’t
>>> enough project libs to require a cache for them.
>>
>> I am not sure
On 2019-07-23 13:38, jp charras wrote:
Le 23/07/2019 à 19:22, Jeff Young a écrit :
Hi Seth,
I think that would work. And you’re right — there probably aren’t
enough project libs to require a cache for them.
I am not sure to understand.
The cache is by lib table, or by library file?
This
Le 23/07/2019 à 19:22, Jeff Young a écrit :
> Hi Seth,
>
> I think that would work. And you’re right — there probably aren’t enough
> project libs to require a cache for them.
I am not sure to understand.
The cache is by lib table, or by library file?
This is very different: if it is by lib
No worries, I got this one.
-S
On 2019-07-23 13:22, Jeff Young wrote:
Hi Seth,
I think that would work. And you’re right — there probably aren’t
enough project libs to require a cache for them.
I’m knee-deep in the router right now, though, so someone else would
have to do it.
Cheers,
Hi Seth,
I think that would work. And you’re right — there probably aren’t enough
project libs to require a cache for them.
I’m knee-deep in the router right now, though, so someone else would have to do
it.
Cheers,
Jeff.
> On 23 Jul 2019, at 09:47, Seth Hillbrand wrote:
>
> Could we
Could we write the global cache in the user's config directory next to
where we write fp-lib-table?
If we cache global, we might not need project-based caching.
-Seth
On 2019-07-23 11:39, Jeff Young wrote:
Hi Rene,
Separate global and local caches would certainly be a refinement.
It’s not
Hi Rene,
Separate global and local caches would certainly be a refinement.
It’s not free, though, as platforms differ on where an appropriate place to
write a global cache is. And the code has to be able to combine the two (that
might be easy or it might not — it’s been too long since I’ve
Is there a reason why this file is even part of the project directory? I
kind of assume it holds the info of all footprints. (If i am misinformed
about that then ignore my inquiry.) Meaning for most users will most
likely be mostly system libs that can easily change while one does not
work on
Hi Seth,
Just performance. IIRC MSW was the real laggard, but even my Mac was more like
7 seconds to 2.
Cheers,
Jeff.
> On 22 Jul 2019, at 17:03, Seth Hillbrand wrote:
>
> Hi Folks,
>
> Odd question here but why do we have fp-info-cache? Was there a bug report
> for these or just speed
16 matches
Mail list logo
