> I guess why immex doesn't work for you because your running code loops > for ever and will never finish, therefore it will never return to immediate > execution state.
Yes indeed. But I don't think I'm explaining the situation well enough. See: http://www.jsoftware.com/jwiki/IanClark/Immex for a full description of what I'm trying to achieve. (The last section is the one to read for this thread.) On Thu, Apr 28, 2011 at 12:45 AM, bill lam <[email protected]> wrote: > My limited understanding of immex is that they are executed just for > exactly one time right after J interpreter just re-entering immediate > state. It will not executed repeatedly because the immex flag (9!:28/29) > will automatically reset. > > Immex (instead of calling 0!:100 from current state) is used to run > user command inside ijx so that user code can run from a clean stack, ie, > the moment J interpreter finished all its backlog and re-entering immediate > execution. > > I guess why immex doesn't work for you because your running code loops > for ever and will never finish, therefore it will never return to immediate > execution state. > > Чтв, 28 Апр 2011, Ian Clark писал(а): >> I've tried runimmx_jijs_ in place of my timer. It does indeed behave >> like APL+Win "Defer", but doesn't allow system events to get a look >> in. >> >> Frequent calls of wd'msgs' during the duty-cycle don't fix the problem >> either: they cause the gui windows to judder and they are >> unresponsive. Although the J session does accept keystrokes with no >> apparent response delays and statements can be executed. >> >> So I'm afraid I shall have to go back to using my timer. Pity. >> >> I would like to know though, how it is that the IJX window can avoid >> judder and be responsive whereas my wd-defined windows can't? Surely >> it's using the same technology? Has it got some other way besides >> wd'msgs' of letting system events get through? >> >> >> On Wed, Apr 27, 2011 at 6:47 PM, Ian Clark <[email protected]> wrote: >> > Hey... then it ought to do what I'm using systimer for! >> > >> > "Immediate" in the 9!:26-29 write-ups suggested to me it was running >> > the given expression there-and-then, at whatever point it was called >> > in the code. >> > >> > I'll try some experiments. It'll be super if it works. Because >> > systimer is a b* nuisance and keeps crashing the Mac if you exit, or >> > try editing anything, with the timer running. >> > >> > >> > >> > On Wed, Apr 27, 2011 at 2:11 PM, chris burke <[email protected]> wrote: >> >> Your description is correct - they run J expressions after return to >> >> immediate execution, and differ only in whether the entries are displayed. >> >> It sounds like APL+Win Defer does the same. >> >> >> >> The main intent was to run expressions in Tools|FKeys, but they or similar >> >> could be used anytime. See also the docs for 9!:26 to 29. >> >> >> >> Chris >> >> >> >> On Wed, Apr 27, 2011 at 5:59 PM, Ian Clark <[email protected]> wrote: >> >> >> >>> There are a pair of verbs in J602 JWD: runimmx0_jijs_ and >> >>> runimmx1_jijs_ . What do they do? >> >>> >> >>> (You may assume I've read about 9!:26 et seq in >> >>> ~help/dictionary/dx009.htm -but don't grok the word "immediate".) >> >>> >> >>> I've been finding runimmx1_jijs_ useful for executing a given >> >>> statement from within J code as if it had been typed into the J >> >>> session. Occasionally doing this behaves differently from running it >> >>> as a bare line of code in a verb. For example: cocurrent 'mylocale' >> >>> --which stops the current locale reverting on exit from the calling >> >>> verb and forces it to remain in mylocale. >> >>> >> >>> Something one wouldn't normally need to do in operational code I >> >>> guess. But it's convenient for writing what used to be called CASE >> >>> tools. (The need arises in-part because I can never spell "cocurrent" >> >>> right first time :-) >> >>> >> >>> Are there implications? Am I misusing the facility? What should I >> >>> really be doing? >> >>> >> >>> An allied matter (at least I think so)... >> >>> >> >>> APL+Win has a facility called "Defer" which posts a statement to be >> >>> executed only when the current process has finished running, typically >> >>> a gui control handler and its nested calls. Good for gui housekeeping. >> >>> I've been approximating this effect by setting systimer to execute >> >>> (once only) the required statement as a callback, a millisecond or so >> >>> in the future. It's a cumbersome way of doing things. Is there a >> >>> neater way? >> >>> >> >>> BTW I'm using a Mac under Snow Leopard. Things which work under >> >>> Windows can't be guaranteed to do so on the Mac, and vice-versa, >> >>> because the system event queues are a bit different. >> >>> ---------------------------------------------------------------------- >> >>> 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
