I didn't test it, but I think f. is only a consquence that verb definitions within a locked script cannot be accessed. Say type that name in a j ide session with only return the name itself.
I cannot see what your big application is so that I cannot offer explanations why it didn't work. Вск, 26 Дек 2010, Henry Rich писал(а): > 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 -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
