kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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.

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.


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