As I understand it, the short hand load'foo/bar' is intended to load an addon package, and a package is fixed at the 2nd level of the folder tree under ~addons. If it can work with other variations under ~addons, it might be a bug.
Птн, 07 Сен 2012, Ian Clark писал(а): > @Raul @Devon > > Yes, thank you both, your thoughts have helped me a lot. > > Though I guess I knew most of that already. But what was bugging me > was this one simple thing... > > My proposed addon 'misc/zulu' is meant for raw beginners. Consequently > I want them to "require" it in as easy a way as possible. > > I've just been experimenting with one of my own addons: math/uu. The > easiest way for me to offer different modes is to have a separate > loader-script for each mode, all residing in the ~addons/math/uu/ > folder. > > Turns out this is the easiest for the novice user to use and remember, too. > > And that's all down to something Raul tells me I didn't know: namely > that (say) ... > load 'math/uu/9' > will successfully load a file called: jpath '~addons/math/uu/9.ijs' > Ditto... > load 'math/uu/trace' > will successfully load a file called: jpath '~addons/math/uu/trace.ijs' > ...and with that I'm home and dry. > > BTW counterintuitively (to me anyway), the following will *not* work > (and I was well aware of it) ... > load 'math/uu/9.ijs' > not found: /Applications/j602/math/uu/9.ijs > |file name error: script > | 0!:0 y[4!:55<'y' > > ...It needs: > load '~addons/math/uu/9.ijs' > >>> mode script: 9.ijs --loaded > > ...But then *this* doesn't work: > load '~addons/math/uu/9' > not found: /Applications/j602/addons/math/uu/9 > |file name error: script > | 0!:0 y[4!:55<'y' > > ...That's going to be a minefield for the novice. It takes long > experience to get familiar with all that. > > It was rough edges like this that made me yearn for a more robust form > of "load/require" statement. > This was the real burden of my elaborate query. Because I knew such > things get up the nose of a novice, making them despair of ever being > sure what they're doing. > > I contemplated a fix to getscripts_j_ so that... > >getscripts_j_ 'math/uu9' > ...would return: > /Applications/j602/math/uu/uu9 > ...instead of: > /Applications/j602/math/uu9/uu9 > This would help a lot, I thought. > > But then while playing about with all this, it occurred to me I could > make it simpler still... > I could contrive to insert entries into PUBLIC_j_ > ...which is built, I think, by: jpath '~system/extras/config/scripts.ijs' > ...A simple change to the base package, of an uncontentious nature, I trust. > > Then I could offer a choice of: > require 'zulu' > require 'zulu1' > require 'zulu2' > ... > require 'zulu9' > > What could be simpler? > > Well, now I've mulled it over for half a day, that's the way to go, I guess. > > Ian > > On Thu, Sep 6, 2012 at 9:54 PM, Raul Miller <[email protected]> wrote: > > On Thu, Sep 6, 2012 at 3:39 PM, Ian Clark <[email protected]> wrote: > >> Re-reading this thread I think my terse reply could be taken for curt. > >> I apologise if this has given offence. > > > > No offense taken. > > > > Disorientation on the other hand? I have been taking some of that... > > > >> 1. Is there a recommended way of doing this, viz offerring and > >> specifying a load with a mode qualifier? > >> > >> 2. Is there a need for such a facility? In what form? > >> > >> From your reply I can infer the answer to 1. is No. Because otherwise > >> you would have pointed me at it. > > > > This is not strictly the case. However, It Is Not That Simple (and > > maybe I want to keep my disorientation to myself...) > > > >> On the other hand there might indeed be a recommendation, which is > >> Don't Do It. And Don't Even Think Of It, because it risks causing a > >> lot of trouble for the implementation of "require". > > > > For some cases of "load differently", yes, this is the probably the > > case. Specifically, if there are significant differences which are > > visible after the load, I would advise against "modal loading". > > > > However, for other cases of "load differently", it might be no big > > deal. Specifically, if you only notice the differences while the > > files are being loaded (for example: optional diagnostics being > > emitted to the session, describing the progress of the load), then > > this could be a reasonable thing. > > > > ... > > > >> I do need a way of loading different combinations of scripts when my > >> proposed addon 'misc/zulu' is first loaded. If there's no recommended > >> way of doing this then I'll cobble up my own. But It would be nice if > >> the different "load" options were (almost) as easy to specify as a > >> simple "load misc/zulu" . I would expect the user of "require" to > >> accept the addon in whatever mode it has been loaded, and to > >> understand that any mode qualifier only applies on first loading. > > > > If your requirement is to actually load different contents, then I > > would present this as different files to be loaded (or required). > > > > In other words: > > > > require 'misc/zulu/normal' > > > > NB. or > > > > require 'misc/zulo/trace' > > > > Note also that the "trace" file(s) could require the "normal" file(s), > > if that helps you. (But why would you not want to be able to switch > > trace on and off after the load?) > > > > If your requirement is to give optional diagnostics on the loading > > process then I would check for the existence of a control variable in > > a locale which is "owned" by your loading process. > > > > In other word: > > > > load 'misc/zulu' [ TRACE_zulu_=: 1 > > > > Your implementation might then look something like this: > > > > cocurrent 'zulu' NB. or coclass... > > ... > > 3 :0'' > > if. 0 = nc <'TRACE' then. > > NB. debug stuff goes here > > end. > > ) > > > > Here, a bare load would get normal behavior. Defining the name with a > > noun would get the debug behavior. If you like you could forcibly > > turn the load tracing behavior off, after possibly previously enabling > > it: > > > > load 'misc/zulu' [ erase 'TRACE_zulu_' > > > > I hope this helps, > > > > -- > > Raul > > ---------------------------------------------------------------------- > > 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
