Mail Archives: geda-user/2015/12/22/14:31:54
--Apple-Mail=_910AF691-986B-486B-98C5-4E332E90AC8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 22, 2015, at 10:52 AM, Peter Clifton =
(petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] =
<geda-user AT delorie DOT com> wrote:
> On 22 December 2015 at 17:38, John Doty <jpd AT noqsi DOT com> wrote:
>=20
>> The one thing that led to many corrupted schematics in one of my =
projects was a change in the attribute promotion policy, promoting =
attributes that I had intended to control in heavy symbols. That made a =
real mess. I suppose that the developer who made the change thought it =
would be helpful, but it was a naughty thing to do.
>=20
> Urg... I will go bang my head hard against a wall if that turned out
> to be something _I_ was responsible for. Definitely a naughty thing to
> do.
>=20
> Was this recently, or some time back?
Maybe five years ago.
> (Peter B and I always pushed
> very hard to avoid breaking things like that - existing user designs
> not breaking was a golden golden rule).
Yes. Maybe to a fault. Even I thought it OK to fix the attribute =
censorship bug, since it involved unstable, difficult to predict =
behavior. Peter disagreed, so all we did was enable a user fix.
>=20
> Generally useful, but needs to be explicitly called out by the target
> netlister I think.
An interesting possibility. Some netlisters don=92t do useful things =
with an unflattened netlist. On the other hand, some (like the SPICE =
netlisters) can work either in flattened or unflattened mode, so you =
need some way to choose.
Some of the gnetlist Scheme primitives have an extra, unused, =93level=94 =
attribute that Ales seems to have intended to use as a control for =
partial flattening. Viewlogic had a similar thing back in the day, but =
it never worked well. Maybe there=92s a design that could work?
> (I recall gnetlist flattens by default, and acts on
> attributes that have their meaning pretty hard-coded).
Some are hard coded. Off the top of my head, refdes, pinnumber, =
numslots, slotdef, slot, pinseq, netname, net, and graphical. A subtle =
peculiarity of graphical=3D1 that doesn=92t seem to cause much trouble =
is that there are really two different cases:
1. Genuinely graphical objects that have no effect on the netlist, such =
as a title block.
2. Objects that communicate something about a connected net, most =
commonly its name.
>=20
> Another example, our implementation of slotting, makes makes shudder
> somewhat. It is one of the few cases where gEDA throws away its
> complete core agnosticism over attached attributes etc.
An associated problem is that slotting uses pinseq in a hard-coded way =
to identify pin function, but some back ends use it to order the pins in =
a netlist. These are not always compatible.
> . We should
> have introduced a more generic mechanism, then "activated" (probably
> with a work-flow specific plugin) it for designs which need that
> behaviour.
Yes.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_910AF691-986B-486B-98C5-4E332E90AC8B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWeaUhAAoJEF1Aj/0UKykRhrMP+QGdtP0A8q02Cf4tYHmAoJOt
+FKWiYsq3QBFuDfaFeAqXcEojaEklkGOeQkwWbycxcXmg330kE/OmK7Rlxx+GD4e
3rZPnErqK6nuH+VB2mGEsqd/oubotEqj/ZCTXAtiES45WGkO4rJ+AxUGbOHzRW0I
mPjWJKmfGrPFsJhte/C29/G1u+fsaaVjC8dbaFqPTcRJbKTGiXv7LRdzWzuqZKvx
ZVN9FwfVUNnBdmsSo7nWoh+1WclO4AiOQKzlrn5frVaPnLY+ppuu9ZV0n3iwvuig
gn6gmKpHDERhLD4VcNZm2k+fj0N1U0hZS5W66xZKKpP37zJNpglASJIaG9C9qg+a
G5j5hz0eQUChZ8O1ZiyKUHqlOoPPLRPryXTaAICLuxzQT8qu7upzKMN8wzjtNRhx
5mh4znR4mo2e8Qkec9IDb+lR5f8rKGeVjZ5DLWqnxcJQz72LXmJn7BlCh4WH4iMD
zj1ZZbL+4stY4Ys6742wP3LaII99UmWADpitDi3SiYzgqB4etn9eM2RlpnyS2PzY
Y3FUKj0MrujbjmC7Gf9NmzxuJQgYAv02U/ooSmE6q03l259wzX2p5/7brr8btLg6
aRmh6AAbD0O2kibA7aCyba80af00NHnC9S7nJb6V+CY7AFClufOVDMIiZaMypHCu
3CZsH1f+g8WeGuJh8Q/a
=Rtds
-----END PGP SIGNATURE-----
--Apple-Mail=_910AF691-986B-486B-98C5-4E332E90AC8B--
- Raw text -