The labs are easily reviewed by anyone. PREPARE simply lets us get on with the subject to learn without getting distracted by unrelated detail.
As we all know from the problems with viruses and so on, there are many better places to hide bad stuff. On Sep 18, 2012 11:37 PM, "bob therriault" <bobtherria...@mac.com> wrote: > Hi Ian, > > I just tested the Averages lab on j701 and PREPARE seems to work, so I > guess that genie is out of the bottle. > > I would use this facility to allow the learner to focus on the specific > lesson rather than the set up details. > > In this way the ability to hide information is one of its gifts, although > I agree that we are relying on the lab writer to be honourable in its use. > > cheers, bob > > On 2012-09-18, at 6:34 PM, Ian Clark 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
