kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/03/2013 08:08 AM, Tomasz Wlostowski wrote:
> On 09/03/2013 02:24 PM, Lorenzo Marcantonio wrote:
>> On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
>>> See my other note.  Just remember what layers things are on instead
>>> of messing around with bitmasks.  So, when you place pin 1, you place
>>> it in the cells occupied by its shape and clearance, and place it (by
>>> reference) in the front, inner1, inner2, back copper, silk front, mask
>>> front, assembly front and assembly back layer sets.
>>
>> Now I got it. You keep a 'by layer' index of entities. It's a good
>> solution, I agree. However when loading/saving/editing a pad (or
>> computing the netlist) it's way more handy to have the list of the
>> layers a pad is on, so I'd keep it around in the pad (not necessarily
>> a bitmask, see other message).
>>
>>
>>
> It's all a matter of the interface. IMHO the biggest problem with the 
> current storage are the DLISTs, that leak the internals of the model to 
> every single file in the code. For instance, if I want to iterate over 
> the tracks, I can't do anything else than:
> 
> for (TRACK *t = board->m_Track; t; t = t->Next() ) {...}.
> 
> The t->Next() leaks an implementation detail (a doubly linked list) into 
> the interface. If somebody wants to replace that list with a spatially 
> indexing container, he'll likely have a problem, and what's worse, he'll 
> have to rewrite a huge pile of code that directly accesses the DLIST..., 
> at least replacing the m_Track (or whatever else) with an iterator class 
> having same interface as the DLIST:
> 
> for (BOARD::Iterator<TRACK> t = board->Iterate ( PCB_TRACE_T ); t; t = 
> t.Next() ) {...}.
> 
> IMHO the first goal is to clean the non-model code of the references to 
> the internals of the model. Then we are free to implement any sort of 
> cell/tree/layer-set indexing in BOARD without having to change the 
> interface.


Tom,


We may have more dialogue when we can see the code.

But, we've had this same conversation before.  I said:

a) we'd be reluctant to change the BOARD model,

b) that you should use class COLLECTOR to avoid any knowledge about where items are
stored.  At least to acquire the items of interest.  You can get anything you want into an
STL container (COLLECTOR and derivatives would be such) that way, and can extend COLLECTOR
in any way you want just to acquire the BOARD_ITEMs.


c) once you have the board items, I suggested you build a facade of your own design for
the TRACK and VIA management.    example:


/// via living in the facade, and MAYBE in the BOARD too.
class RVIA
{
	// a SEGVIA, never NULL.  But it may or may not be in BOARD.
	SEGVIA*	m_via;

	bool IOwn()
	{
		// is it in the BOARD yet, I really don't care either way yet.
		return !m_Via->Next() && !m_via->Prev();
	}
};


/// track living in the facade, and MAYBE in the BOARD too.
class RTRACK
{
	// same idea
};



Your facade can be RVIA's and RTRACKS, indexed and augmented with any data you want.  When
your user is done routing, or taking a break gesture-wise, make a pass through your facade
and add any TRACKs or VIAs that you own (see IOwn() above) i.e. that are not in the BOARD,
to the BOARD.

This should be possible since your VIEW is what you graphically draw from, not from the BOARD.

You are correct about the model being somewhat exposed.  But the model is working nicely
everywhere else, and it is fast.

We may have more dialogue when we can see the code.



> 
> For the P&S I also needed some sort of lightweight copying (I call it 
> branching), that is creating lots of copies of the root model that are 
> slightly changed wrs to the root (I use it for making the traces 
> "springback" when the cursor is moved back and for comparing different 
> optimization strategies). I learned that having links between items 
> stored in the items makes such copying mechanism difficult to implement.
> 
> My experience after writing the P&S router is:
> - restrict access to the model through Add, Remove, Replace methods and 
> iterators (in my case QueryColliding/NearestObstacle).
> - store connectivity information in the container, not in the items 
> (JointMap). This way it's possible to replace any set of segments/vias 
> in the newer branch without having to modify the old ones or the parent 
> node that hosts them.
> - copy - modify - replace instead of modify live thing. I know it's 
> slower but at least in case of the P&S, the bottleneck is collision 
> finding...
> 
> Tom
> 
> PS. about more than 64 layers - I attached an example flag set class. Of 
> course it's not as fast as a bare int/int64 (4 assembly instructions 
> instead of one/two), but it brings type safety and automatic 
> serialization (it's just a demo written in 20 minutes, not a quality code).
> 
> 
> 
> _______________________________________________
> 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
>