Henry wrote: > …and a global assignment only for the place that you know is the top level?
Trouble is, if you're using JQt IDE to maintain an addon, the top level changes. ++ During development, it is your buildfile: /myaddon/source/build.ijs. ++ But once a user downloads it via pacman, it is myaddon.ijs Maybe it's safe enough to use MYDIR=: in both build.ijs and myapp.ijs. But "safe enough" is not in my vocabulary now I've been bitten. Maybe again, it's only a problem for someone like me using JQt to develop a suite of addons which need to be maintained in-tandem. But that someone commands special attention due to the damage s/he can inflict. I'm repeatedly drawn back to the idea of badging a script with its full path. No levels of indirection. ++ The huge advantage is diagnostic: if bugs are regressing and you think it's due to the wrong version of a script being loaded, then there's a complete and effective procedure for guarding against it, and checking whether it has happened. ++ The huge disadvantage is that if a script is moved, it's not clear who or what has the duty to alter the badge. But it's easy at several different stages to detect that the badge is wrong. And there's never the slightest doubt as to what the badge should be. Ian Clark On Wed, 10 Apr 2019 at 23:44, Henry Rich <[email protected]> wrote: > Then why not use > > MYDIR =. > > in each script, and a global assignment only for the place that you know > is the top level? > > Henry Rich > > On 4/10/2019 5:15 PM, 'Pascal Jasmin' via Programming wrote: > > > > I think its about global name sharing and clobbering each other > > > > MYDIR =: pattern to set current dir > > > > load 'MYDIR/subdir/file1.ijs' (will change MYDIR if same name used to > track) > > > > load 'MYDIR/file2.ijs' (wrong MYDIR) > > > > one solution is to repeat the anonymous 4!:4 { 4!:3 expression instead > of assigning its result. The other is to organize files into a sense of > hierarchy such that global variables TOPDIR, MAINSUBDIR are part of the > application and may always be set before "deep" files are loaded. > > > > A somewhat related request (already at System/Interpreter/Requests ) is > to allow an optional left arg to 0!:n , but on second thought, the only > relation is to remind you of it :P > > > > > > On Wednesday, April 10, 2019, 12:57:54 p.m. EDT, Henry Rich < > [email protected]> wrote: > > > > > > > > > > > > I was thinking the same thing, and when I look in the interpreter, I > > find that the script index IS stacked and restored in jtlinf(). > > > > Can someone show a simple example of how the script-index field in an > > entity gets corrupted? > > > > Henry Rich > > > > On 4/10/2019 11:23 AM, Raul Miller wrote: > >> As described, that will work for scripts in the same folder, but will > >> break if those scripts require or load scripts from different folders > >> which implement the same mechanism. > >> > >> What seems to be missing here is use of a stack for tracking this > >> external dependency (and I think it has to go into the implementation > >> of the interpreter, though putting something into the implementation > >> of 'load' could do the trick). > >> > >> Thanks, > >> > > > > --- > > This email has been checked for viruses by AVG. > > https://www.avg.com > > > > > > ---------------------------------------------------------------------- > > 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
