Le 25/04/2014 11:29, Lorenzo Marcantonio a écrit : > Still looking at that code after the SEGVIA cleanup. > > AFAIK the track/via DL-list on the board is kept sorted (or maybe only > grouped?) by netcode, so all the segments of a net are contiguos on the > list. Presumably the 'rebuild board connectivity' button re-sorts the > list when something changes substantially (usually the netlist). > > I'm in the 'merge collinear segments' section in clean_segments(); > inside the main 'for each track which is actually a TRACK', just after > the flag and no_inc definitions there is a funny looking for loop > (actually a while in disguise :D). I think the idea here is to find > other tracks attached to the start point of the segment in exam, using > TRACK::GetTrack(), from the next on until the end. > > In pseudocode it seems to work in this way: > > looping with segStart from the next of the current segment > find a segment from segStart on attached to the current segment begin > point > if found: > if it's not a TRACE or if the width is different: > exit the loop > if there isn't another segment like the one found before: > set the flag > exit the loop > exit the loop > > ...then proceed to process the segment found and does the same with the > other endpoint in substantially the same way. > > So... have I got it wrong? it's me or it isn't a loop at all? whatever > happen it hits a break. I don't know the exact logic needed here, but > shouldn't retry with another one segment if the width mismatches or it > hits a via? why the only one segment connected? shouldn't it work in > a tee, too? > > Typical example: > -S1b- > --S1--O--S2-- > | > S3 > | > > (S1b is overlapping partially with S1 and ending on the via O). > Shouldn't S1b be 'eaten' by S1. Or it is somehow detected as > unconnected? (how? both edges are connected to S1) *OR* the routine is > expected to only handle the case > > --S1--.--S2-- > > (where the . is only a coincident endpoint)? If that's what meant for > collinear the the routing makes more sense (but then why a loop which > doesn't ever repeat?) > > Another thing: > > in TRACK::GetTrack(TRACK*, TRACK*, int), if I got the idea correctly, it > first looks walking in both the directions from the this position > looking for a matching track, for 50 paces (probably to optimize the > usual case) and then do an exhaustive search on the passed range. > > In this function: > 1) (only nitpicking on this:P) instead of the ugly: > > previousSegment = nextSegment = this; > > why not > > previousSegment = this->Back(); > nextSegment = this->Next(); > > so that explicit check for this are not needed? > > 2) instead of doing the general search why simply don't continue the > bidirectional walk until it its the passed limits? > > 3) what if I wanted to continue the search (for example in the 'loop' of > the cleaning routine)? with a bidirectional search you can't express it > (unless you return also on which side you found it and keeping track of > two search ranges). > > 4) in the backward iteration, how could a TRACK* have a PCB_T type? > isn't PCB_T the whole board? > > That's a lot of questions but that section of code really confused me... > > Thanks in advance, >
Many parts of this code come from the beginning of Pcbnew. A lot of things have changed now. I am thinking the 'merge collinear segments' section should be rewritten from scratch. -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
