On 04/10/2012 07:14 AM, Wayne Stambaugh wrote: > On 4/10/2012 2:43 AM, jean-pierre charras wrote: >> Le 10/04/2012 01:23, Wayne Stambaugh a écrit : >>> On 4/9/2012 2:41 PM, jean-pierre charras wrote: >>>> Le 09/04/2012 17:37, Wayne Stambaugh a écrit : >>>>> 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 >>>> Yes, tracks are the most common object in the file. >>>> In fact, track is the single object that really needs to be optimized in >>>> file. >>>> (I have boards with more than 120 000 tracks) >>>> In order to reduce the time to read (or write) the brd file, an option >>>> could be do not repeat some parameters >>>> if they do not change. >>>> Mainly track width and track layer values could use the last value read. >>>> So consecutive tracks having the same width and layer (very common in >>>> Pcbnew) need only 2 parameters (Y and Y coordinates), >>>> This trick is often used in many applications. >>>> >>> This could be a nifty optimization. Are the track objects currently >>> sorted? This would need to done to maximize this optimization. >>> >> Tracks are currently sorted by net and then by proximity. >> So net code (and/or net name) should be output only once. >> Inside a given net, most of tracks have the same width, >> so width parameter should be rarely needed. >> >> format like: >> (tracks >> (net 1) >> (track(xy 91.6686 85.4837) (xy 91.6686 81.8134) (width 0.6096) (layer 0)) >> (track (xy 91.6686 81.8134) (xy 101.6686 85.4837)) >> (via (xy 101.6686 85.4837) (size 1.6096) (layerspair back front)) >> or: (via thru (at 0.082 0.038) (size 0.08)) >> >> (track ... ) >> ( via (xy 129.6686 95.4837) (size 1.6096) ) >> (net 2) >> ... >> ) >> ) >> >> or something like sounds good for me. >> >> blind/buried vias need a layerspair definition. >> through vias do not need this parameter. >> >> Note also to minimize time in some search functions, tracks and vias are >> "sorted" by proximity >> and the track/via order in list should not be modified. >> >> > I like the grouping by net. This seems more readable to me. Since > tracks are already sorted this way, it seems like a natural way to go > from the track object to the file output. I may use "layers" instead of > "layerspair" and group the tracks by net so it looks something like this: > > (tracks > (net 1 > (track (xy 91.6686 85.4837) (xy 91.6686 81.8134) (width 0.6096) > (layer front)) > (track (xy 91.6686 81.8134) (xy 101.6686 85.4837)) > (via (xy 101.6686 85.4837) (size 1.6096) (layers back front)) > ) > (net 2 > ) > ) > > Any one else have any thoughts on this before I make any changes?
Yes, introduce the CTL_CLIPBOARD flag now for Format( aControlBits ) so we don't lose the ability to put a fully meaningful wire on the clipboard. One that could travel from one board to another, meaning the layer needs to be named and the net needs to potentially be named also. This is the "varying contextual circumstances" that I warned about in the Format() function. I don't want to see it dumbed down too much too early for lack of the big picture. _______________________________________________ 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
