On 4/9/2012 9:50 AM, Dick Hollenbeck wrote: > > Wayne, regarding: > > DRAWSEGMENT::Format(), it concerns me in two minor ways: > > case S_SEGMENT: // Line > aFormatter->Print( 0, "line (pts xy(%s) xy(%s))", > FormatBIU( m_Start ).c_str(), > FormatBIU( m_End ).c_str() ); > > > a) I don't think this is s-expression, the xy(...) should be (xy ...) > > > b) It may be worth considering losing one token, namely the "(draw line" > might be > "(gr_line". (Really, I am just trying to cover my ass.) I don't want to be > blamed for > the slow parsing speed later. :) Any reduction in another token that is > simple like > this is worth considering. Each token in the stream is another delay, which > cumulatively > may be noticeable. Maybe a common prefix for the graphic primitives in this > DRAWSEGMENT::Format() would allow you to omit one token. > > Suggesting "gr_" or something like it prefixed to the primitive, instead of a > full token > "draw ". My concern is speed later. However, I'm guessing you are > reserving the right > to makes changes later. :) > > > I'm guessing it really gets important on the more common objects like tracks > and vias, > *especially tracks*, which end up being about the most common object in the > file. > > > ALSO: > ========== > > Maybe we can get the (track...) on one line as a default, this will help > also, since we're using two lines now. > > Whitespace in this format is not supposed to matter, but again, I am trying > to get out of the way regarding parsing speed later.
As of now, the deepest indentation level is 6 spaces. I know the indentation is responsible for a lot of the additional file size but getting rid of it would seriously reduce the readability file. I'm not sure there is an elegant solution to that problem. Wayne _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
