Yes packages are fixed at the 2nd level, but my understanding is that the ability to load scripts from those packages located at levels below that is intended behaviour. eg: load 'math/deoptim/demo/eg_deoptim'
If it turns out that is not intended, then I second Ian's request! On Fri, Sep 7, 2012 at 9:34 PM, Ian Clark <[email protected]> wrote: > Oh dear. > > Can I request its promotion to a feature? > > On Fri, Sep 7, 2012 at 3:41 AM, bill lam <[email protected]> wrote: >> 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
