) (03/20/90)
Bjorn, there must be something else wrong. I get #S(FROB :FOO 1 :BAR :BAZ) back from (lose-frob). Either your code got hammmered somewhere else, or something in my environment is weird. I'm running a vanilla Rel6 band (although with a lot of my own code loaded). anyone else have this problem? -- clint
rice@SUMEX-AIM.STANFORD.EDU (James Rice) (03/21/90)
In my experience this problem will only become manifest when you compile this stuff into a file and load the file, not c-sh-c in Zmacs. Whenever you have quoted constants in your source code these are loaded into read-only memory when you compile file. I have also seen this behavior with defstructs, though not this particular instance. I'm not at my Exp right now so I can't check it. When it has happened to me I've always been able to copy the data structures out of read-only memory fairly simply. Note: you cannot do what I thought you should be able to do in this case, i.e. backquote your constants and not quote them. For example, you cannot say: (defvar *my-mutable-thing* `(a b c)) because CLtL (and the TI implementation) states that backquote can be optimized into quote for constant structures and that quoted structures are intrinsically read-only. This is really a bug in CL, which really needs a simple syntax for denoting a mutable literal. Rice.
Victor@JOHN-JAMESON.DOCS.UU.SE (Bjorn Victor) (03/23/90)
Some debugging hours later: As you might have seen when reading my bug report, I get the error in GETHASH, when it tries to lock the generic-function method hash table of #'COPY. The lock is read-only. This problem is not unique to DEFSTRUCTs, but to any type other than FIXNUM, SYMBOL, CHARACTER and CONS, i.e. the types that have an entry in the method hash table in the vanilla band. As Clint said, the problem does not exist in a vanilla band. In a vanilla band, the generic-function method hash table of #'COPY is in WORKING-STORAGE-AREA. The problem is that the generic-function method hash table of #'COPY somehow gets copied/transferred into the MACRO-COMPILED-PROGRAM area, which as all lispm hackers know, is read-only. I still don't know who does it, but someone does. I do a full GC with max-gen 3 before saving, but it would seem to be a grand bug if the GC moved things between areas. HASH-TABLE-REHASH does the Right Thing, constructing the new hash table in the same area as the old one. I've found a work-around: After cold-boot, I redo the DEFGENERIC form for COPY (which seems to give me an "invalid" hash table in the FEF), and do (COPY T) to have it automagically reconstructed. This first call to COPY has to be done with SYS:%INHIBIT-READ-ONLY bound to T. Yeach. Give me an update to System Software Design Notes, please TI. --Bjorn Victor Victor@John-Jameson.DoCS.UU.SE Dept. of Computer Systems or Uppsala University, SWEDEN Victor%John-Jameson.DoCS.UU.SE@uunet.UU.NET
Victor@JOHN-JAMESON.DOCS.UU.SE (Bjorn Victor) (03/27/90)
TI answered my SPR this friday, and they tell me I haven't got the current patch level of CLOS, and tell me to obtain the current patches from TICARE. Questions: 1. What is TICARE? How much does it cost to get the patches? (Joey Maxie recently implied on the Info-TI-Explorer list that it's expensive). 2. Is there any other way to obtain patches? Since I've got a support license, it would seem fair if patches were free, and that I could copy them from somebody else with FTP. 3. What are the current patch levels of the standard release systems, NFS and IP? Could someone publish this info semi-regularly on the Info-TI-Explorer list? Is this beginning to smell Apollo, or have I got the wrong impression? (Apollo don't even tell you there is a patch until you tell them you found the corresponding bug, and don't send out patch/update tapes as a standard service). Yours, --Bjorn Victor Victor@John-Jameson.DoCS.UU.SE Dept. of Computer Systems or Uppsala University, SWEDEN Victor%John-Jameson.DoCS.UU.SE@uunet.UU.NET