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
