I agree your proposal can be useful for developers, but it also
introduce a change in behavior that has been there for many
years.  The next qt will add the following line

finalize_jqtide_^:(3=(4!:0)@<) 'finalize_jqtide_'

so that a user can customize or override wdhandler or any other
functions and can survive addon updates.

Вс, 22 май 2016, Raul Miller написал(а):
> I think that avoiding coping measures on the grounds that at some
> future point in time a proper fix should be done is wrong.
> 
> The right time for avoiding those coping measures is when that proper
> fix is available.
> 
> If the issue is motivation, you need that anyways - but having a
> system which can be used in the mean time is important for motivation.
> 
> Thanks,
> 
> -- 
> Raul
> 
> 
> On Sun, May 22, 2016 at 1:02 PM, bill lam <bbill....@gmail.com> wrote:
> > 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
> ----------------------------------------------------------------------
> 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

Reply via email to