kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>