commercial. immediate investigation to solve the problem. so far not gl paint related. On May 20, 2016 8:33 PM, "Raul Miller" <[email protected]> wrote:
> What production environments? > > If we are talking about classroom environments, or development > contexts, then shutting down the system is counter-productive. > > But I would like some more information on what you are talking about. > > Thanks, > > -- > Raul > > > On Fri, May 20, 2016 at 7:23 AM, bill lam <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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" <[email protected]> > 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 < > [email protected]> 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" < > [email protected]> 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 < > [email protected]> 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" < > [email protected]> 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
