The old lab system was great in its time. I now think we'd be better off with a simpler and more direct mechanism. I've taken a stab at the direction I think we should go the the 'simple project managed execution' facility in JHS (which can be used in any front end). I think it makes for adeguate, but much simpler labs, and has the advantage it can be used for managed execution with any script.
On Tue, Sep 18, 2012 at 9:34 PM, Ian Clark <earthspo...@gmail.com> wrote: > Mac "Spotlight" shows me several Labs in j602 base libraries have > PREPARE-blocks, eg lapack.ijt -- I count some 40 others. > > I may be adopting an unpopular stance here, but having only yesterday > discovered this facility, I don't like it, and wouldn't commend its > use. It's sneaky. And I don't accept it offers any facility that can't > be done in an open way, and done better. > > Lab: lapack.ijt, for example, uses it exclusively to define and > execute transient verbs via (3 : 0)'' embedded in the Lab (.ijt) file > itself. These verbs look innocuous enough to me, so no blame accrues > to the Lab author. But that's not the point. > > One of the attractions of the Labs facility to the end-user is that it > lets the user retain full control of the J session, whilst delivering > (on-demand) a series of session input lines, which are faithfully > echoed in the IJX session. In other words, it gives the appearance of > an invisible teacher leaning over my shoulder and (with my permission, > of course!) typing on my keyboard. > > An illusion, I know, but a comforting one. Really we know that _jlab_ > has been loaded in the background... and my! -- it's busy. > > But this is subtly yet vitally different from having the Lab .ijt file > itself executing arbitrary verbs silently on its own authority. It's > not a matter of the Labs facility being *unable* to execute such > silent verbs, but of assuring the user that it never will. Even if > that assurance is implicit, and has no legal substance. > > Having a PREPARE-block undermines that assurance. It means a Lab can > deploy trojans, leaving no record of their having been executed. To > detect such code, and discover what it actually does, I need to > locate, and peruse, the .ijt file itself. > > Let me argue for PREPARE *not* to be migrated to j701 in its present > form, and for the facility to be "detoxified" in j602. I don't say > "withdrawn", because that would break a lot of fine Labs. May I > suggest that a PREPARE-block *never* conceals its content from IJX, > though perhaps tagging it with: "for system use only, please ignore"? > > Ian > > On Tue, Sep 18, 2012 at 10:31 PM, bob therriault <bobtherria...@mac.com> > wrote: >> Hey everybody, >> >> In J602 there was a markup Instruction used in labs called PREPARE that >> would bracket J commands to allow you to do things behind the scenes when >> running a lab file .ijt >> >> I wonder if this would be an option to have scripts load without having the >> learner aware of it. I think that the opengl lab works this way. The actual >> lab script is in 602/system/extras/labs/graphics/opengl.ijt and you can see >> PREPARE working on the first page. The authoring lab touches on this as I >> remember. I am not sure that this facility has transferred to 701 but if it >> hasn't it would be nice if that functionality was retained. >> >> Cheers, bob >> >> On 2012-09-18, at 1:39 PM, Ric Sherlock wrote: >> >>> On Wed, Sep 19, 2012 at 7:52 AM, Ian Clark <earthspo...@gmail.com> wrote: >>>> >>>> Yes, I too would like to combine the whole thing in one single addon. >>>> You'll recall the extensive correspondence (17 posts) that followed my >>>> original proposal to do just this, and how best to do it? >>>> http://www.jsoftware.com/pipermail/programming/2012-September/029259.html >>>> The LAPACK way would be to keep separate "loader" scripts in >>>> format/zulu and run them like this: >>>> load 'format/zulu/lite' >>>> load 'format/zulu/bare' >>>> ...etc. >>>> I can have as many loader scripts as I can fancy a need for. A lot >>>> less trouble than releasing and maintaining three separate addons. But >>>> I got the hint from the forum that using load/require in this way is >>>> "untidy", and that the preferred programmer interface for using any >>>> addon is quite simply: >>>> load 'category/addon' >>> >>> I don't think you should see this as untidy. I don't believe that this >>> functionality is undesirable or unintended. I suggest you have the >>> main/default package named zulu.ijs, but that you include your other >>> scripts in the same addon. Then (load 'format/zulu') will work and >>> load the script most users will need, but (load 'format/zulu/lite') >>> and (load 'format/zulu/bare') will work too if the user needs them. >>> ---------------------------------------------------------------------- >>> 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
