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
