Infinite loop is bug, but replacing ok box with interrupt button is not a proper fix to the gl paint problem. So far gl paint is the only case that results in an infinite loop, so that I would prefer a proper fix to the gl paint problem itself.
I suspect it is a deficiency of Qt graphic backend, since popup box is at the top of z-order, the presence or absence of popup box should not interfere the other windows. Вс, 22 май 2016, Jan-Pieter Jacobs написал(а): > 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 -- 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
