[Xcircuit-dev] XCircuit debugging

[Eric Y. C. <er...@al...>]

Hi.  I am trying to debug a broken connectivity problem in XCircuit.
This problem relates to generating pcb netlists.  After running
through the tutorial on the bridge rectifier, a correct netlist
is output with respect to nodes, but there is no connectivity.
In other words, the diode bridge is floating with respect to the
input.

Anyway, I figured that I needed to first upgrade to the latest
(unstable) version, 2.5.4.  Unfortunately, this does not come
up with usable menus.  The menus are all green, with no text in
them.  I replaced the .Xdefaults with the new .ad file, and
neither one worked.  All green.

Since green was the problem, I decided to remove all references
to green in the .Xdefaults file for xcircuit.  The odd thing is
that this had very little effect.  When I changed one of the 
lines, the menu fill changed to gray (even if I changed the
entry to blue).  When I removed all lines, except for the
*foreground and *background lines, the problem still occured,
indicating that the "green" issue was hardcoded in the program.

I then removed all instances of green (Green3) etc from all c
and header files, and the problem persisted.  Also, I compared
the source code in these sections with the working version 2.3.3.
There appeared to be no major changes.

That means that the green is coming from someplace else.  There
are no hardcoded references anymore to green in the code, header
files or .Xdefaults, but the menus are still coming up green
filled.  The instances of green in the stable build are in the
same places, and the stable build works.  So, it is very likely
that the green is coming from an entirely unrelated portion of
the program generating a side effect.

There is a very suspicious section in which a custom color table
is loaded, but this is the same as in the stable build, which
works.  This code is apparently triggered when it is found that
the current colors do not match within some kind of measure
which is 512 in the code.  Changing this number to 1024 has no
effect, and neither does commenting out the custom color table
routine.  Obviously, what is going on is that the green is
loaded into the color table by this custom generation routine,
and there is some essentially unrelated change that is either
corrupting the color table or assigning two important indices
to either close or identical values of green.

It may be difficult to duplicate this problem elsewhere since
the X server on my system is limited to 256 colors.  Since 
there is a working build, it may be possible to work on back
by means of binary subdivision, but this will require a lot
of patching back.  Is there a better way to fix the problem
by going right to it?  Does any of this ring a bell?

Thanks,
Eric