gEDA-bug: [Bug 707064] Recursive vs iterative

[Krzysztof KoÅciuszkiewicz <707064@xxxxxxxxxxxxxxxxxx>]

> 1. is_net_fully_connected() is recursive, not iterative. Since C doesn't
> optimise tail calls, it means that on designs using very complex nets we
> might see stack exhaustion.

Even if rewritten to be iterative, we would have to maintain a stack
of visited net segments ourselves - in addition to a hash the current
version uses. This might give us better control over memory usage and we
could fail gracefully when allocation fails - but will likely complicate
the function. Is gschem even run on systems where stack does not grow
automatically?

> 2. is_net_fully_connected() treats a netname attribute as a connection,
> but that's not reflected in the doxygen comments.

The Doxygen comment in is_net_fully_connected() says:

    Net is fully connected when it connects at least two separate
    entities. "netname" attribute being attached to one of the net
    segments counts as an connected entity as well.

Any suggestions how to reword this to make it more clear?

> 3. We allocate and build a hashtable for each and every net object in
> the entire design, every time we draw, which is rather expensive. Is
> there any way of optimising things so that the "fully connected" flag is
> only updated when a user modifies the design?

That is on a TODO list - we would have to keep "fully connected" cached
flag in the net objects, or maintain a separate cache of precomputed
values per net segment.  The latter would not require making changes to
libgeda, as this is a feature only gschem would make use of.  It seems
the most difficult part is to catch all cases where the cache should be
updated.

Any suggestions on the caching approach?

-- 
You received this bug notification because you are a member of gEDA Bug
Team, which is subscribed to gEDA.
https://bugs.launchpad.net/bugs/707064

Title:
  Remove unconnected net cues for netname connected nets

Status in GPL Electronic Design Automation tools:
  New

Bug description:
  This came up after a presentation with potential users.

  The red cues on the end of unconnected net was perceeved as a nice
  warning that something was unconnected.

  Their expectation was that a net connected at one end should lose the
  second cue (on its unconnected end) if the net is named. This could be
  implemented either to mean "has a netname=" attribute, or that it is
  connected to something which has one.

  This helps to preserve the semantic that "red splodge" == something to
  fix.

  We also noted that the pin cues were not nearly as visible as they
  ought to be when projected!


_______________________________________________
geda-bug mailing list
geda-bug@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-bug