I have figured out what was going on, I think. The decision of whether to mark a name as locked or not is done when 0!:00x is executed. That decision applies to all verbs loaded under that execution of 0!:00x. Verbs created outside of 0!:00x are not locked.
0!:100 does not alter the locking flag, so 0!:100 unlocked_script_text when executed inside of a verb that is running in a locked 0!:00x is going to lock all its definitions. This means that you have trouble if your locked startup script needs to load some unlocked names, because the whole script is executing under the 0!:0 that was used to load it. You could write out your unlocked scripts to a file, if you are sure you have write access to a file. But I found a more elegant solution: the last thing in the locked startup script sets an immex phrase (9!:27); then the script terminates, closing out the locked 0!:0, and then right away the immex phrase is executed, NOT locked, so that it can use 0!:100 to define the unlocked verbs. Henry Rich On 12/26/2010 11:14 PM, Don Guinn wrote: > I wondered about that too. Once a name is locked it stays locked. I wrote a > simple test script to find out that that was not the case. It worked like > one would want it to work. When the name was redefined in an unlocked script > it was also unlocked. > > On Sun, Dec 26, 2010 at 7:16 PM, Henry Rich<[email protected]> wrote: > >> OK; but the question is, What is a locked script? I load and execute a >> locked script, which loads another (unlocked) script. When is f. >> disabled? Can it ever be reenabled? >> >> The use of create f. and destroy f. does not occur in my >> application until the unlocked script gets control. >> >> There seems to be some persistent state that says "don't do f." but I >> can't work out the rules that describe it. >> >> IT MIGHT BE that once a verb is loaded locked, any reassignment to the >> name is also locked. That would explain what I'm seeing. But so would >> many other explanations; I'd like to know what's really happening. >> >> Henry Rich >> >> On 12/26/2010 7:32 PM, bill lam wrote: >>> This is a design feature that f. becomes an no-op in locked scripts. You >>> did post any detail about how your big application implement inheritane, >> I >>> can only guess you also used the same sort of f. inside the create verb >>> which did not cause fatal error but executed in sockmux locale instead of >>> the connxactn locale. >>> >>> Вск, 26 Дек 2010, Henry Rich писал(а): >>>> I am distributing an application and I would like it to be a locked >>>> script. But when I lock the script, it doesn't work. >>>> >>>> The error messages make me suspect that an object has not been destroyed >>>> properly. I use a 'connxactn' class that extends my 'sockmux' class. I >>>> am thinking that the code in connxactn >>>> >>>> destroy =: 3 : 0 >>>> destroy_sockmux_ f. '' >>>> ) >>>> >>>> which should destroy the sockmux when the connxactn is destroyed, is not >>>> working properly because of a reluctance of the interpreter to disclose >>>> destroy_sockmux_ when the script is locked. >>>> >>>> Is this a known problem? >>>> >>>> >>>> Even if it is, I don't understand why my application doesn't work. I >>>> distribute a loader file as a locked script. When that file runs, it >>>> connects to a server and pulls down the big unlocked application. The >>>> locked script does not create any of the objects that seem to be causing >>>> the trouble, and it seems to run fine. The trouble comes when it starts >>>> the big unlocked application. >>>> >>>> The big application includes the same socket library that the loader >>>> uses, so when the big app is loaded it overwrites names that had been >>>> loaded by the locked file. None of these names would be executing at >>>> the time they were reloaded, so I would think they should be overwritten >>>> with non-locked versions that would not exhibit any anomalies of >> disclosure. >>>> >>>> The only connection between the locked and the unlocked code is that the >>>> locked script is running while it calls the initialization code for the >>>> unlocked app. None of the reloaded verbs is suspended, though. >>>> >>>> To repeat: if the loader script is not locked, all is well. If it is >>>> locked, the big unlocked script fails. >>>> >>>> Henry Rich >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
