Hello,
Since few weeks I use the newest KiCad version 4.0.6 under Archlinux x86_64.
Since today morning I get an error running CvPcb:
Errors were encountered loading footprints:
PARSE_ERROR: Expecting “(” in input/source
‘https://github.com/KiCad/Connectors_Molex.pretty’ line 38 offset 60 from
/build/kicad/src/kicad-4.0.6/common/dsnlexer.cpp : Expecting() : line 361
Could someone correct this please?
Thanks in advance,
Michael
I bet one of the later merges has screwed something up.
A better way to report problems with the libraries would be to open an issue over on the affected github repo.
Man the error messages in kicad are not helpful at all. Couldn’t they at lest tell us the offending footprint?
This is strange. If i clone the official repo and checkout the current master, i can open the library without problems. But i can not open the lib i add via the github plugin.
I opened an issue
fix committed. There is an error with the 3d path of one component.
It should now be fixed again. Sorry for the inconvenience and thanks for reporting.
The developers really need to have a session improving error messages. Libraries will always contain errors like this, so clues to the cause help everyone
If the error message would have contained to affected footprint i would not have lost 2 hours searching. So yea i totally agree. (I don’t care what c++ file found the error. I want to know which footprint created a problem.)
I see an even more basic shortcoming than the content of error messages. The development effort should assume from the start that a typical real-world installation will contain library errors. Many (perhaps the majority?) of users establish and maintain their own libraries and these libraries are typically touched by several (perhaps dozens) of hands so errors are almost inevitable.
Citing the offending location in a library file (as suggested by @Rene_Poschl) is definitely an improvement over citing the failed line of executing code. It would be even more helpful if program execution could continue after encountering an error. This probably means backtracking and removing a portion of the offending library from the executing program. Using this current incident as an example, it could mean that a particular Molex connector is not available for use, its symbol is displayed as a large “?”, etc. Or it might mean that the entire Molex connector library is ignored. (In either case, the error message should alert the user to the situation.) At least an error would not cause the entire program to crash.
Dale
Doesn’t that line indicate the offending line of the offending library?
pretty libs have many files in them. (one file per footprint) In this case there are over 100. All of which have been changed yesterday.
You are right. Line 38, offset 60 was correct. But where in the file is only my worry once i find the offending file.
The point I was making. Executable code hopefully gets cleaner over time. Libraries constantly get broken, by careless edits or renaming synchronisation problems between symbols, footprints and 3d models