kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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