Peter -- We had a discussion about the slotting issue last night while hanging out with the Free Doggers. We agreed that we'd try to figure out exactly what bug you were seeing, and try to figure out exactly what problem my original pinseq patch was creating. And then we'd fix it, of course.
I went back and reviewed your original post about this on geda-dev. I'm trying to understand precisely what has gone wrong. Please forgive my slowness. You say: > If you have a slotted component, it is possible to set a slot=n > attribute - and the component's pin numbers update. > If I have said component with slot=1, and I change to slot=n (n != 1), > I > see a pin number update. Once I have slot=n (n !=1), no further > updates > to the slot= attribute have any effect on the pin numbers. > > The log window ends up with many: > > component missing pinseq= attribute So the bug is that if you change slots on a part from, say 3 to 2, then the pin numbers drawn on the symbol don't update, right? Next you say: > The pinnumber replacement (and the whole slot update) is keyed on the > pinseq numbers, however this patch causes them to be re-written for > different lots. e.g: > > inverter with pinseq=1 and pinseq=2 for slot=1 > > becomes > > pinseq=3 and pinseq=4 for slot=2 > pinseq=5 and pinseq=6 for slot=3 The answer is: yes, this is the intended behavior of my patch. The idea is that spice-sdb gets the netnames attached to pins by using "get-pin-attribute-by-pinseq", or some similar function, and it needs some way to specify not only which pin, but also which slot. THerefore, accessing slotted parts' pins via modulo arithmetic seemed like a straightforward way to do it. As part of implementing this, I wrote the pinseq info back into each OBJECT since previously for slots 2, 3, 4.... no pinseq info was ever stored on the OBJECT, which seemed like an oversight. The question here is: Does this cause any breakage of netlisters? Or is it just unexpected behavior to you as you work on the code? Next, if the problem is that changing slots from 3 -> 2 doesn't update the pin numbers, then isn't the fix to locate the code which handles slot updates, and then figure out what's wrong there? I could be wrong, of course, but it seems to me that the thing to do is make the slot update code understand the modulo scheme for handling pinseq attributes. If you agree, then I can move forward to see what type of fix to implement. Cheers, Stuart _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
