Browsing through the Addons folder in jwiki, at those Addons which consist of collections of associated scripts rather than one integrated application, I see several pages where the author assumes you can load a choice of script via a sentence of this form:
load 'category/addon/script' The author of LAPACK assumes it, as this example shows... http://www.jsoftware.com/jwiki/Addons/math/lapack#An_Example_of_Using_LAPACK ...and the Developer's Guide seems implicitly to recommend it... http://www.jsoftware.com/jwiki/Addons/Developers%20Guide#Shortnames If this behaviour is a bug -- and it ever gets fixed -- several significant addons are going to suffer. On Fri, Sep 7, 2012 at 10:39 AM, Ric Sherlock <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
