I do not see this change is helpful in production environment. End users can not see or understand what had happened inside the wdhandler unless those end users themselves are J users. At any rate, the system has to be shutdown for maintenance when there are errors trapped by wdhandler whether there is an infinite loop or not, because the production system has become unreliable.
Пт, 20 май 2016, Raul Miller написал(а): > Are there any good reasons, though, to not include this change in a > near future release of qt.ijs? > > (As I understand it the only issue here is that it gives a way of > regaining control of a J session. And while, ok, this might be a > hypothetical problem for a hypothetical situation, I think we have a > lot of work to do on making J into something where creating an > end-user executable is easy and streamlined before "regaining control > of a J session" can be thought of as a serious problem. Still, if I am > wrong, I would like to know some specifics about the people who are > hurt by this regaining of control from an infinite loop error state.) > > Put differently: what else do I need to do to get this change into qt.ijs? > > Thanks, > > -- > Raul > > > On Fri, May 20, 2016 at 6:51 AM, bill lam <bbill....@gmail.com> wrote: > > At least not a big problem for me, since the infinite loop only > > occurs for paint event. And if it happens I use non-intrusive > > smoutput instead of wdinfo as I had mentioned. > > > > Пт, 20 май 2016, Raul Miller написал(а): > >> 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 > > > > -- > > 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
