← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema Default Library Field Names

 

Wayne Stambaugh wrote:
Dick Hollenbeck wrote:

Wayne Stambaugh wrote:

I haven't looked at JP's changes yet. I was the one who originally proposed getting rid of the .mdc file. I got a little side tracked with all of the things I was working on. I'm almost done with my new EEschema find dialog work. Once the next release is out, I'll commit the new find work then I'll revisit getting rid of the .mdc file. If I remember correctly, I wasn't really happy with changes to the component library file format using my original concept. Then Dick started working on his DSN lexer so I thought I would wait until he got that stabilized and then use it for the new library file format. I'll see if I can make getting rid of the .mdc file and moving to a DSN style file format at the same time. I'll make sure not to break reading the current file format. This shouldn't effect anything you are planning on doing.

Wayne


Wayne,

The latest TODO.txt file talks about the need for a simple tool which will generate the keyword tables for any grammar. With this tool, you should only have to maintain a single text file of keywords for each grammar.

I would say the description of the needed tool is pretty good in the TODO.txt file, and most anyone could write it.


Dick,

I took a look at it today because the changes conflicted with some changes I made to TODO.txt. I like the idea of using a separate tool and CMake to generate the lexer keyword table. After I commit my EESchema find dialog changes, I will take a look at it. I've been holding off until the next stable release to commit these changes but if I don't see any movement in that direction I may just go ahead and commit them. I don't think the changes will be too disruptive.


Whoever gets to it first would be what I suggest. Eventually I will if no one else does.

You can see a simple example of a recursive descent parsing environment at the bottom of the dsnlexer.cpp file. It could also be the basis of clipboard pasting support. For copying support, there is the STRING_FORMATTER to generate a string in ram.

The first keyword after the opening '(' can be used to vector to a keyword specific paste function, and invoke a different parser, depending on what is on the clipboard. There are many examples of parsing recursively in the specctra import code.

The LINE_READER foundation gives very exact location specific error messages when the input is bad. I realized I had broken this concept when I started returning multi-line strings as single tokens. There was no way to say exactly on which line an error occurred when I started returning multi-line strings. So I backed off and now all tokens must reside on a single line, and purely for the purpose of an exact error message. It will output the exact line number and character offset.

Just loading a library file with a text editor and converting to a DSN format should be pretty easy. It might be reasonable to START with clipboard support, this way you do not have to commit to a file format change until folks like it.


I hadn't considered clipboard support as a starting point but it may be a good place to start since I had planned on changing the library file format to use the new lexer. The project file issue that Brian mentioned may not be a bad place to start either. Creating a project file lexer would remove the current wxFileConfig code from WinEDA_App() and all of the config structure tables from each Kicad application's top level window object. In either case, I'm not planning to start working on it until after the next release.

Wayne


VESA and the library crew can copy a symbol from the symbol editor to the clipboard, paste from there to a text editor, edit in a text editor, and paste back into the symbol editor via clipboard. If you could just offer this much support, based on the notion that exact error messages will be issued, and that the new format is SELF DOCUMENTING, it should be good value, and a win IMO.

No need to wait for me any more (at least not on this subject) :-)

Doing the tool will clarify in the writer's mind what is required to generate the enum {} and the keyword table.


Dick


Cool. Maybe whoever gets to it first should simply grab the task off the TODO.txt file by adding their name in place of ANYONE:


This seems like a task that anyone (new contributor?) wanting to jump in and help with could reasonably do, providing that they know C++. :-)


Also, using the FILE_LINE_READER and maybe strtok() is probably how I would go about reading the keywords.


It is probably only a 1/2 day's work, and half that is figuring out how to tell CMake to build this tool natively, (even in a cross compiler environment) and to invoke the tool in the proper way AFTER IT IS BUILT, natively. CMake can do this, I know, but some reading is probably necessary.


command line options that make sense to me now are:

1) specify the input text file name

2) specify the enum prefix, each enum value then becomes <prefix>_<keyword>

3) specify the output path for the *.h file (the name can be auto-generated from input file). or make it the full path, not important.

4) specify the output path for the *.cpp file.


Could be others...

ensure all keywords are lower case ASCII, no UTF8.

---------------
Outputs into the *.h file:

// do not edit this file, it is auto-generated by <tool>

extern array;
enum {}

extern unsigned arrayz; // or a define that gives the count of keywords in the array

--------------

Outputs into the *.cpp file:

// do not edit this file, it is auto-generated by <tool>
keyword [] = {

// sorted alphabetically, using the same colating sequence as what a
// strcmp() would determine, ala dsnlexer.cpp's
// static int compare() function.


{ enum, string },
( enum, string }
:
etc.

};

unsigned arrayz = count // not needed if we go with the #define in the *.h

----------------------


It should be fun for somebody, and I have no doubt you'd do it exceptionally well Wayne.


Dick








Follow ups

References