[Xcircuit-dev] netgen-1.5: Application Error: unknown option "-under"
When the hoterrors option is enabled in tkcon, and an error occurs, it is displayed. At the same time it has a binding applied to it so that when the mouse hovers over the text message, it is underlined. With newer versions of Tcl/Tk an error occurs when the error message is moused over. Here's a screen shot: http://files.suncup.net/netgen_apperr.png This issue was reported as a bug to the tkcon project and fixed. https://sourceforge.net/p/tkcon/bugs/54/ #54 Use of '-under' conflicts with 8.6.6 '-underlinefg' http://tkcon.cvs.sourceforge.net/viewvc/tkcon/tkcon/tkcon.tcl This issue exists in the xcircuit-3.10 code base as well. (magic-8.2 does not have this issue). Due to opencircuitdesign's customizations to tkcon.tcl, we just can't pull a newer version of tkcon.tcl and use it directly, so we need to either patch our version with the fix, or pull the latest version of tkcon.tcl from sourceforge and customize again. Patching our copy can be done quickly with a sed command: sed -i -e 's/-under /-underline /' tkcon.tcl https://github.com/mooredan/netgen-1.5/commit/79406914639cd2b2d94aaefb23ce5a668c39669d https://github.com/mooredan/xcircuit-3.10/commit/b6f940307ff345da2fc50f5ac8c94a9b046c1032 ___ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
Re: [Xcircuit-dev] Make Matching Symbol Application Error
Sounds good. For now, I’ll keep the hack in to avoid the error. Once the alternative solution is in place, I’ll back it out and give it a whirl. I’m enabled for now. On Sun, Nov 11, 2018 at 16:19 Tim Edwards wrote: > Hello Dan, > > > Lines 1565-1569. What's happing is that a pointer to a Tcl_Obj is being > > passed to the function. https://www.tcl.tk/man/tcl/TclLib/Object.htm > > The longValue (datatype: long) is retrieved from this structure. Its > > value correctly corresponds to the hex string. It is the cast to the > > int and then back to a long on line 1566 is the culprit. When the > > handle's value is greater than what can be stored in an int, then data > > loss will occur. The if on line 1566 no longer evaluates to true and > > the function doesn't return and falls through to returning the > > TCL_ERROR. > > > > I'm not sure where the "too large" message is supposed to appear, but > > I didn't notice it in either the console nor in the terminal that > > executed xcircuit. > > > > As an experiment, I commented out lines 1566 and 1569 and recompiled. > > Now things worked out as expected. That is, the form got expanded with > > the pin list, and once Okay'ed the symbol is created. ...and no error. > > > > I didn't dig further to determine why handles need to be restricted > > to the size of an int, but it doesn't seem to matter (yet). > > > > Anyone have some insight on this? > > This code is dependent on the definition of "int", which as you may > know, is a wishy-washy concept in C which is often (but not necessarily) > defined as 4 bytes on a 32-bit system and 8 bytes on a 64-bit system; > and also the definition of "long", which is an equally wishy-washy > concept and may be twice the size of "int". . . or not. I no longer > remember why I wrote that snippet of code, but I think that I was just > guarding against the possibility that the Tcl object "longValue" would > be the same length as a pointer. If it is shorter, then the error > would alert me that I need to do something completely different here, > which is either to find some Tcl_Obj representation that is always the > length of a pointer, or (probably a better approach anyway) to avoid > the use of a memory location as the "handle" to an object in xcircuit, > and instead generating a random (and likely much shorter) value for > the handle of each object as needed, and create a hash table out of > that. > > Removing lines 1566 to 1569 "almost always" solves the problem, but > because you are chopping half of the object's unique address off (this > is assuming it is probably a 32-bit vs. 64-bit issue), the remainder of > the number is "probably" unique to the object, but that is not guaranteed. > > So while it is highly unlikely that you will ever encounter an error > caused by removing those lines of code, I would rather solve the problem > in the "correct" way by assigning a unique handle ID to each element and > then doing look-ups from a hash table. > > I'll put that on my to-do list, but feel free to send me a reminder if > you find I haven't gotten around to it after a week or so. > > Regards, > Tim > > ++-+ > | R. Timothy Edwards (Tim) | email: t...@opencircuitdesign.com| > | Open Circuit Design| web: http://opencircuitdesign.com | > | 19601 Jerusalem Road | phone: (240) 489-3255 | > | Poolesville, MD 20837 | cell: (408) 828-8212 | > ++-+ > ___ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
[Xcircuit-dev] Make Matching Symbol solution
OK, So I investigated this a bit further and found that the found in xcircuit.c is there to protect the long handle being stored into a pointertype that is typedef'ed off a u_int. The code in xcircuit.h establishes the pointertype: 107 #if SIZEOF_VOID_P == SIZEOF_UNSIGNED_INT 108 #define Number(a) (void *)((u_int) a) 109 typedef u_int pointertype; 110 #elif SIZEOF_VOID_P == SIZEOF_UNSIGNED_LONG 111 #define Number(a) (void *)((u_long) a) 112 typedef u_long pointertype; 113 #elif SIZEOF_VOID_P == SIZEOF_UNSIGNED_LONG_LONG 114 #define Number(a) (void *)((u_long_long) a) 115 typedef u_long_long pointertype; 116 #else 117 ERROR: Cannot compile without knowing the size of a pointer. See xcircuit.h. 118 #endif The aforementioned code in xcircuit.c assumed that pointertype was typedef'ed from u_int. However, on my system SIZEOF_VOID_P is the same a SIZEOF_UNSIGNED_LONG. Therefore the cast down/up code is not needed. A solution is to put these same preprocessor directives around the code in xcircuit.c as well. https://github.com/mooredan/xcircuit-3.10/commit/1225d030e0d010fb17dda26e151081b5a3df4d89 ___ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
[Xcircuit-dev] How to compile Xcircuit on a Mac (OSX)
https://github.com/mooredan/xcircuit-3.10/blob/master/README.OSX git remote add mooredan https://github.com/mooredan/xcircuit-3.10.git git fetch mooredan git cherry-pick d91a6358d83e0675b2dcf1513dcc1be8aac5a917 Dan Moore moore...@suncup.net Tigard, Oregon, USA ___ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
[Xcircuit-dev] Make Matching Symbol Application Error
This issue has been observed on both on macOS (MacBook Pro 2017, 10.14.1
Mojave) and the current LTS Ubuntu running on in VirtualBox on the same
machine. It is not observed on a contemporary Kubuntu installation on
modern hardware. Presumably, this has not been observed in most other
installs.
The issue is that an Application Error popup occurs with attempting to
execute "Make Matching Symbol" from the Netlist menu. This screen capture
shows what happens:
http://files.suncup.net/xcircuit_error_MakeMatchingSymbol.png
Here's the full error message:
bad option "H7FBA25B6C010": must be make, name, parts, library, handle,
hide, unhide, or bbox
bad option "H7FBA25B6C010": must be make, name, parts, library, handle,
hide, unhide, or bbox
while executing
"object $handle parts"
(procedure "xcircuit::getsubckttext" line 8)
invoked from within
"xcircuit::getsubckttext $schematicname"
(procedure "xcircuit::getpinlist" line 4)
invoked from within
"xcircuit::getpinlist [page label]"
(procedure "xcircuit::addpinarranger" line 48)
invoked from within
"xcircuit::addpinarranger .makesymbol"
(procedure "xcircuit::promptmakesymbol" line 13)
invoked from within
"xcircuit::promptmakesymbol [page label]"
invoked from within
".xcircuit.menubar.netlistbutton.netlistmenu invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 50)
invoked from within
"tk::MenuInvoke .xcircuit.menubar.netlistbutton.netlistmenu 1"
(command bound to event)
I debugged this to the Tcl_GetHandleFromObj function in the xcircuit.c
file. Here's the function:
1550 int
1551 Tcl_GetHandleFromObj(interp, objPtr, handlePtr)
1552 Tcl_Interp *interp; /* Used for error reporting if not
NULL. */
1553 Tcl_Obj *objPtr;/* The object from which to get a int. */
1554 void **handlePtr; /* Place to store resulting int. */
1555 {
1556 long l;
1557 int result;
1558
1559 if (objPtr->typePtr != ) {
1560 result = SetHandleFromAny(interp, objPtr);
1561 if (result != TCL_OK) {
1562 return result;
1563 }
1564 }
1565 l = objPtr->internalRep.longValue;
1566 if (((long)((int)l)) == l) {
1567 *handlePtr = (void *)objPtr->internalRep.longValue;
1568 return TCL_OK;
1569 }
1570 if (interp != NULL) {
1571 Tcl_ResetResult(interp);
1572 Tcl_AppendToObj(Tcl_GetObjResult(interp),
1573 "value too large to represent as handle", -1);
1574 }
1575 return TCL_ERROR;
1576 }
Lines 1565-1569. What's happing is that a pointer to a Tcl_Obj is being
passed to the function. https://www.tcl.tk/man/tcl/TclLib/Object.htm The
longValue (datatype: long) is retrieved from this structure. Its value
correctly corresponds to the hex string. It is the cast to the int and
then back to a long on line 1566 is the culprit. When the handle's value
is greater than what can be stored in an int, then data loss will occur.
The if on line 1566 no longer evaluates to true and the function doesn't
return and falls through to returning the TCL_ERROR.
I'm not sure where the "too large" message is supposed to appear, but I
didn't notice it in either the console nor in the terminal that executed
xcircuit.
As an experiment, I commented out lines 1566 and 1569 and recompiled. Now
things worked out as expected. That is, the form got expanded with the pin
list, and once Okay'ed the symbol is created. ...and no error.
I didn't dig further to determine why handles need to be restricted to the
size of an int, but it doesn't seem to matter (yet).
Anyone have some insight on this?
Thanks,
Dan Moore
moore...@suncup.net
___
Xcircuit-dev mailing list
Xcircuit-dev@opencircuitdesign.com
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
