On Windows 10 (64-bit) nightly builds, has anyone else noticed a change in the way symbol libraries are loaded at the startup of the schematic editor? For the past few revisions, I am getting errors thrown at startup primarily in the atmel.lib. It appears to be related to the mapping between the .lib and the .dcm files and aliases.
I just wondered if this is something known, or if I am doing something different (wrong)?
Cheers.
r
There is a new legacy file parser. It’s a bit more strict about the input. I’ve always regarded the dcm file as optional, but the new parser flags warnings about missing aliases.
Thank you. I use very few of the “kicad” libraries, so I can probably manage this by cleaning up my legacy projects. But I just didn’t want to get to a revision level where I could not edit old stable projects in my archives.
Yes, I also experienced that, starting a day or two ago. I chased down a few of the squawks and it looked like there were typos in the part names, or at least a discrepancy between the name in atmel.lib and atmel.dcm. That’s rather puzzling, because I thought the *.dcm files were automagically regenerated from the *.lib files after an editing session on *.lib.
(Can somebody confirm that, or set me straight about that last statement?)
In defense of the new parser, it DID catch an error I had made several months ago regarding an alias.
Dale
From the one hand, it’s helpful for library creators/developers and reveals shortcomings in the documentation field, but from the other hand it’s very frustrating for ordinary users who didn’t know what was happening.
Of course (paraphrasing Spartans): This… is… Nighliessssss!!! 
The .mdc (Modules Documentation File) was always regenerated when corresponding .mod file had been changed. The content of .dcm file doesn’t have their “mirror” in .lib file, so any regeneration can’t be done.
I haven’t had a chance to really chase this to ground, but I have checked the new software against some legacy projects. I have one project with maybe 1500 components and about 15 hierarchical sheets. This used to load in one to two seconds. With the new parser (and all the unused libraries cleaned from the preferences) the new load time for the schematic is about 20+ seconds. It would seem load time has increased by at least a factor of 10 (perhaps as much as 20). This is actually a pretty significant loss in productivity. I’m hoping this is not a permanent condition.
r
I haven’t tried to measure it, but it seems like the time to load EESchema is significantly longer.
And . . . the symbol editor (part library editor) is acting up. I (sometimes) see “Unhandled Exception” errors when I try to save a symbol after editing.
I have version (2017-02-14 revision 877a65d) on a Win7/64 machine.
Dale
I am generally a fan of the bleeding edge work in Kicad. The development community does a fantastic job! This particular issue, though, has been significant enough for me, that I have decided to roll-back a few revisions for a while and see how things sort out. I cannot afford the loss in productivity and the risks of crashing. I’ve had both in the past couple days.
I’m holding on http://downloads.kicad.org/windows/nightly/kicad-r7628.1bcbbb4-x86_64.exe for a while.
Hopefully this will get picked up by the developers and be resolved.
r
Thx for the pointer - was just looking for a new one to load 
This is supposedly fixed in the 16 Feb 2017 nightly build, release r7660.9375e18. See the bug report for more info.
http://downloads.kicad.org/windows/nightly/kicad-r7660.9375e18-x86_64.exe
Dale
Yes. Crashing is fixed. My legacy project schematic load time has gone from <2 seconds to > 45 seconds. I cannot live with that type of delay. I’ll revert back for now. Maybe I can strip the legacy project from all the old library file links and improve, but I’ll have to test that another day.
r