I also happened to run into the infinite popup problem, both when trying to get started writing J GUI's (gave up because of this) and when using plot (accidentally not specifying options in the way they should be).
I agree that in that last case, it was probably a bug in the plot package, but in my opinion, the user or developper should never irrevokably loose control over the environment under whatever circumstance, also not when it's due to his own ignorance, or a bug in a package he's using. Certainly not when trying to promote J as the ideal tool for interactive experimentation. If all experimentation should be stored in scripts, how is the workflow still so different from that of compiling languages? So I would be a huge fan of a feature like an interrupt button for repeating popups, or making jbreak cleanly interrupt this kind of endless loops. Just my two cents. Jan-Pieter On May 20, 2016 12:41 PM, "Raul Miller" <rauldmil...@gmail.com> wrote: > Has this been a big problem, for you? For anyone? > > The problem of being a J programmer and losing control of the system > is an immediate problem, and I think it's a bigger problem. > > Also, for those hypothetical end users who might be "confused" by an > option, it would be possible to "remove choices on their behalf" if > that were actually important. (That might be somewhat arrogant, > though, since this "removal" does not seem to improve anything for > them.) > > -- > Raul > > > On Fri, May 20, 2016 at 5:48 AM, bill lam <bbill....@gmail.com> wrote: > > IMO errors reported in wdhandler reflect there are some > > programming bugs or unexpected behavior. If it occurs in > > production systems then end users who have no J knowledge should > > whatsapp the screen shot to the developer. Providing more choices > > will confuse end users further. > > > > Пт, 20 май 2016, Raul Miller написал(а): > >> I am seeing some odd things here. One of which is that the previous > >> documentation for wdquery -- > >> http://www.jsoftware.com/docs/help701/user/script_winlib.htm#wdquery > >> -- seems to no longer be valid. Another is that I can not find > >> documentation for wdquery for the current release. (And I am seeing > >> other oddities in behavior, but I am going to stop trying to enumerate > >> those oddities with those two observations.) > >> > >> Anyways, perhaps wdhandler should be changed, replacing > >> > >> wdinfo 'wdhandler';'error in: ',wd_fn,wd_err > >> > >> with something like > >> > >> if. 0~:wdquery 'wdhandler';'error in: > ',wd_fn,wd_err,LF,'continue?' do. > >> echo 'DISABLED_',wd_fn > >> ('DISABLED_',wd_fn)=: (5!:1<wd_fn)5!:0 > >> erase wd_fn > >> end. > >> > >> (but, beware email induced line wrap) > >> > >> In other words: > >> > >> [1] Give the user the opportunity to continue. Depending on details of > >> other parts of the system, this may or may not result in further > >> problems. > >> > >> [2] If the user opts not to continue, set aside the definition of the > >> current event handler (which failed) and disable it. (Hypothetically > >> speaking, we might be able to skip the setting aside part, because the > >> definition should be in a script. However, in some cases it might not > >> be.) > >> > >> Thoughts? > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> On Thu, May 19, 2016 at 11:59 PM, bill lam <bbill....@gmail.com> wrote: > >> > I checked agin, it is the local noun wd_fn inside wdhandler. > >> > so perhaps you can try > >> > ". wd_fn,'=:empty' > >> > or > >> > 4!:55 <wd_fn > >> > inside the catch block. > >> > > >> > Пт, 20 май 2016, bill lam написал(а): > >> >> the first few rows of wdq (global set inside wdhander) should > provide that > >> >> info. see j user manual or jwiki for wd documentation. > >> >> On May 20, 2016 6:55 AM, "Raul Miller" <rauldmil...@gmail.com> > wrote: > >> >> > >> >> > Is there a systematic way of determining which verb name is the > name > >> >> > of the currently running event handler? > >> >> > > >> >> > Thanks, > >> >> > > >> >> > -- > >> >> > Raul > >> >> > > >> >> > > >> >> > On Thu, May 19, 2016 at 7:27 AM, bill lam <bbill....@gmail.com> > wrote: > >> >> > > c++ jqt side did not know what had happened on the j engine so > it will > >> >> > keep > >> >> > > on calling J on paint. You need to make j paint verb a no-op > after the > >> >> > > first popup. > >> >> > > > >> >> > > For debug suspension, you may want try catchd instead of catch. > >> >> > suspension > >> >> > > in the presence of events is rather troublesome. IIRC all events > except > >> >> > > paint are discarded during suspension, so that you may still get > infinite > >> >> > > in suspension. > >> >> > > > >> >> > > what I used to do is set > >> >> > > wdinfo_z_=: smoutput_z_ > >> >> > > in order to debug gl paint error. > >> >> > > On May 19, 2016 5:28 PM, "Raul Miller" <rauldmil...@gmail.com> > wrote: > >> >> > > > >> >> > >> So... maybe it would make sense to replace > >> >> > >> > >> >> > >> wdinfo 'wdhandler';'error in: ',wd_fn,wd_err > >> >> > >> > >> >> > >> in wdhandler with something like > >> >> > >> > >> >> > >> if. -.wdquery 'wdhandler';'error in: > >> >> > >> ',wd_fn,wd_err,LF,'continue?' do.throw.end. > >> >> > >> > >> >> > >> ? > >> >> > >> > >> >> > >> Except... I tried that, and throw. was not sufficient to stop > the > >> >> > >> infinite condition with debugging disabled, and that line of > code > >> >> > >> never runs with debugging enabled. So there is something else > going > >> >> > >> on, also... > >> >> > >> > >> >> > >> Perhaps the best compromise for development purposes would be to > >> >> > >> disable the offending handler (erase the name) if the user > elects > >> >> > >> cancelling out of it? > >> >> > >> > >> >> > >> Thanks, > >> >> > >> > >> >> > >> -- > >> >> > >> Raul > >> >> > >> > >> >> > >> > >> >> > >> On Wed, May 18, 2016 at 6:36 PM, bill lam <bbill....@gmail.com> > wrote: > >> >> > >> > the popup dialog box is raised by a try catch block in the > verb > >> >> > >> wdhandler, > >> >> > >> > since it does not throw an error after the popup, there is no > >> >> > suspension. > >> >> > >> > the gl area partially hidden by the popup box is repainted > and since > >> >> > the > >> >> > >> gl > >> >> > >> > paint or any other jqt events has no knowledge that there has > been an > >> >> > >> error > >> >> > >> > in j wdhander being caught so there is an infinite loop. You > may add > >> >> > >> some > >> >> > >> > codes in the j paint verb to detect that error condition. > >> >> > >> > > >> >> > >> > this had been reported but fixing it is a low priority. > >> >> > >> > On May 19, 2016 5:09 AM, "Raul Miller" <rauldmil...@gmail.com> > wrote: > >> >> > >> > > >> >> > >> >> Currently, if I am using the gl commands for an isigraph > control, and > >> >> > >> >> there's an error, I get behavior which I do not understand. > >> >> > >> >> > >> >> > >> >> (1) I get a popup telling me that there was an error (and > giving me > >> >> > >> >> the details of the error. > >> >> > >> >> > >> >> > >> >> (2) I only have an "OK" option on that popup. > >> >> > >> >> > >> >> > >> >> (3) When I click "OK", execution resumes as if there were no > error > >> >> > >> >> (presumably on the line following the line with the error. > >> >> > >> >> > >> >> > >> >> This quickly leads to an infinite loop condition where my > only option > >> >> > >> >> is to shut down J. > >> >> > >> >> > >> >> > >> >> At the very least, I think I should get an option to have > the error > >> >> > >> >> stop execution somehow. > >> >> > >> >> > >> >> > >> >> (13!:0]1 avoids this problem, but why was it a good idea to > make me > >> >> > >> >> lose control of the J session in the first place?) > >> >> > >> >> > >> >> > >> >> (I'm not sure if this goes in jsource, since I think this is > a jqt > >> >> > >> >> issue, not a j engine issue. Please let me know, though, if > there's a > >> >> > >> >> better forum for this topic.) > >> >> > >> >> > >> >> > >> >> Thanks, > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> 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 > >> >> > >> > ---------------------------------------------------------------------- > >> >> > >> 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 > >> > > >> > -- > >> > regards, > >> > ==================================================== > >> > GPG key 1024D/4434BAB3 2008-08-24 > >> > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > >> > gpg --keyserver subkeys.pgp.net --armor --export 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 > > > > -- > > regards, > > ==================================================== > > GPG key 1024D/4434BAB3 2008-08-24 > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > > gpg --keyserver subkeys.pgp.net --armor --export 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
