It's also a counsel of perfection when you're frenziedly debugging, restarting J each time. You want as fast a turnaround as you can get. Soon you're hacking your startup.ijs in a Notepad session, left open...
...Not for the faint-hearted. But my point was not that it tripped **me** up -- but imagine what my (old) modal-load technique would do to a less experienced user, who doesn't have the powerful tools I have. They'd be crawling up the wall...! That's why I've junked it, in favour of something much *much* simpler. (I communicate, too.) On Sun, Sep 9, 2012 at 3:09 PM, Linda Alvord <[email protected]> wrote: > Following your moral, I NEVER make my own profile and instead use what comes > with the package of J. If I want to change things I must do it each time > manually so I know I won't forget at some point that I changed it myself and > it won't work the same way if someone else uses it. > > This probably works well for me as I am not creating commercial applications > and more interested in communication. > > Linda > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Ian Clark > Sent: Sunday, September 09, 2012 8:00 AM > To: [email protected] > Subject: Re: [Jprogramming] load/require in different modes? > > Right... I'd like to report back. > > Kind people have tried to engage seriously with my problem -- which I did > feel was general enough and important enough to concern others. I thank them > and I'm deeply grateful. I feel I owe it to them to explain my change of > thinking, and how it has come about. > > -- It's instructive --and this list serves as a repository (via > pipermail) for a social history of J usage and development. It's instructive > in a "come-all-ye" sort of way, so if I can stop some young man going down > my recent road then it's not been a journey wasted. > > I've just spent 3 days writing, debugging, documenting and stress-testing > 'format/zulu' --as the addon is going to get called. > I've had a lot of good fun that is funny (...funny-peculiar, not > funny-ha-ha). And I've turned my fleeting impression of the JAL Addon > apparatus as a KISS sort of facility ("keep-it-simple, stupid") into a deep > and abiding respect. Tinker with it at your peril. > > Here's the briefest of outlines of the problem to be addressed. The > Addon: 'format/zulu' will be coming out real soon now. Just as soon as I've > settled the present problem to my satisfaction. So we can leave the > forensics till it comes out. Then ... RTFC! > > Addon: 'format/zulu' consists of 11 separate scripts, five of which can be > meaningfully loaded in just about any combination. And I've been using it > and preening it for years, and it all works fine. Yes really. (I won't say > more here, because I want you to focus on the problem of this thread, not > zulu itself.) > > By Friday I ended up with an interface looking like this to the end-user... > > require 'format/zulu' [ MODE=: '-t -4 -a -p -s -f' > > The resemblance to the unix command-line is deliberate. Of course few addons > need a set of flags this prolific. Mostly it'd be something simple like: > > require 'category/addon' [ MODE=: 3 > > MODE can reside in any locale, usually _base_ or _z_. If it's absent then > zulu.ijs creates it as a transient noun. There's a nice way of doing that > inside a script like this... > > MODE=. ". 'MODE' > > I offer it as something to meditate upon. It's deceptively straightforward. > > Actually, to simplify the subsequent code, I use something a bit more > elaborate but the same broad idea: > > default=. ([: *@#@". [) >@{ ] ; [: ". [ > MODE=. 'MODE' default '-t -4 -a -p -s -f' > > Now trust me -- it all works, and I got zulu debugged and finalised, even to > writing a long elaborate lab called zulu.ijt -- and I sat back and thought > about it. And I did not like it. Not one little bit. > > It's so riddled with gotchas it's unbelievable. Actually it's all utterly > believable... if you've spent a career cobbling up fancy interfaces on > unpromising platforms. Nothing you haven't seen before. > But the gotchas don't appear until you start making heavy use of the result. > > One fine gotcha is that if you neglect to erase MODE when you've finished > with it (...in all visible locales...!) then it lies in the long grass like > an upturned rake, coming back and hitting you when you're otherwise > preoccupied, wasting hours of your precious time. > There's a way round that (--how about a dyadic load, folx?) -- but it soon > lands us in another fine mess. Like: what if there's a script error? > Wouldn't you like to see a diagnostic message? Well, you might > -- if you're lucky. And our dyadic-load can only mop up its temporary > MODE_z_ noun if it runs to completion! > > I could go on for hours in this vein, but I'll spare you the details. > Suffice to say that I'm throwing it all away and going back to basics... > > require 'format/zulu-strict' > > require 'format/zulu-lite' > > require 'format/zulu-bare' > > load 'format/zulu-sandbox' > > ... > > The above are alternatives, not meant to be called in turn. They may have > different names than I've used here. You can guess their usages from their > names. > > Each will be an independent addon. But I won't be needing 2^5 of them after > all. 6 or 7 at most. And they're so easy to write. I've just written and > tested a fresh one, and it took me 2 minutes. And so easy to use. And to > teach, and to learn about. > > The fact that they'll need their own separate folders in ~addons/ is no big > deal. They be getting their own maintenance history anyway, since they have > quite different audiences, and I won't be releasing them all at once. > They'll need separate pages in http://www.jsoftware.com/jwiki/Addons ...but > each page will be short and pithy. Once uploaded to svn, most of them will > never need to be altered again. > > But the biggest benefit of all is how zulu (j602) will look in menu: > Studio > Labs... > > I'll need to write seven IJT files instead of one. But they'll each have 5 > or so pages of easy stuff, instead of the 40+ pages of rambling complexity I > was getting into. Just to manage the UNIX-like tags would have taken a > course in itself -- and who'd have had the patience with that? > > * * * * * > > This story has a moral. Two in fact. > > 1. A life spent in computer science and software development (of the wrong > sort) can sometimes lead you down the wrong path, when it comes to product > design. > > 2. The JAL Addon facility -- especially its automated web documentation -- > is a masterpiece of carefully contrived simplicity. > Don't mess with it. Don't gild the lily. Using it the KISS way can actually > be best for the end-user, yourself, ...everyone. > > Ian > > On Sun, Sep 9, 2012 at 12:12 AM, Ian Clark <[email protected]> wrote: >> 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 > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
