On 4/10/2012 9:37 AM, Dick Hollenbeck wrote: > On 04/10/2012 08:34 AM, Dick Hollenbeck wrote: >> 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. > > Also introduce any CTL_OMIT_NET, CTL_OMIT_LAYER_BECAUSE_IT_might_be_faster, > flags you > need to perform the outputting of the shy wire, since the decision to output > the shy wire > will have to be done by the caller, not in the Format() function.
You've got to keep an eye on those shy wires :) > > >> 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 > _______________________________________________ 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
