Memory limit is not working. The problem with breaking is typically related not to length of operation or its complexity, but rather whether it uses a lot of memory.
This happens often even with such simple operations as this (takes 1.3 Gb with 10000000#1000): 'c'8!:2 ] 9!:20'' 268,435,456 'c'8!:2 ] 7!:2'([: $ #&1)&.> 4000000#1000' 595,119,424 (It should have given 'out of memory' -- further, open Task Manager to observe that J did not release the memory(*), before a call to 7!:0''). Now keep increasing the size (value before #) until swapping starts (execution should take a minute or more). Now try to use the yellow icon to break -- it won't work right away, only after a while. Rationale: such situations occur when using brute force and you want to push it, so that the engine tells with memory limit "that's too far" -- OK, let's try something else. When the disk starts swapping, it takes J longer to react to the yellow icon. For some reason, the memory limit does not work. J is slowly allocating a huge amount of memory exceeding the limit, which causes the swap. As a result you have to wait for long minutes before this process completes. Often it takes too long and you just have to kill J process. ________ (*) J does not relase the memory after execution of the last statement so any call to GUI now such as Close [X], may produce |out of memory: wdhandler_0_ | wdq=: wd'q' --- Eric Iverson <[EMAIL PROTECTED]> wrote: > How is jbreak 601 not working? Have you studied the doc in the User Manual > on 'Interrupt Execution'? Verify with some very simple tests that the basic > mechanism works in simple cases. For example, create a script with a verb > that does a while loop that will run for 10 seconds or so and then test > whether clicking the yellow J icon interrupts execution or not. Most J > programs can be interrupted fairly promptly. There are some long running > executions that are very localized and don't check for break, but I would be > surprised if that were the case for the general problem you report. > > ----- Original Message ----- > From: "Thomas Costigliola" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, May 11, 2006 1:20 PM > Subject: [Jbeta] RE: Tardy graphics > > > > Regarding the thread "Tardy graphics" (Pasted below). > > > > I am having the same problems and am looking into solutions. Eric suggests > > to put the execution and UI in seperate threads. Any chance of a J > > threading library in the future? > > > > Also, I read that these changes have to do with the new jbreak facility. I > > must say that frankly the new jbreak facility does not work for me. The > > documention says to send the signal twice to break execution immediately. > > However, it takes between 30 seconds and 1.5 minute for the first instance > > to execute when I click the jbreak icon in my 'quick launch'. And when I > > am finally able to click it again my J window does not repaint itself and > > breaks only after 3 to 5 minutes of waiting (if at all). It seems like > > there is a lot more work to break in J6 where in J5 all I had to do was > > hit ctrl+break. > > > > > > > >> > >> > >>===================================== > >> > >> > >>There are significant changes in the area of windows message handling in > >>601. These change were enabled by the change to how break is handled but > >>were driven by a desire to simplify the front end and make it more > >>portable. > >> > >>In 504 the J Engine when running periodically and frequently polled the > >>front end with a callback. The callback dispatched windows messages in the > >>front end. The main purpose of dispatching the messages was to enable > >>detection of break signals (Ctrl+break etc in windows forms). The > >>secondary > >>effect was that messages such as requesting a repaint of a window that was > >>uncovered were also handled. But messages that could cause important state > >>change or require signalling J events were filitered out and discarded. > >>This > >>code was very messy and complicated, was quite against the spirit of the > >>windows api, and has been a continual source of subtle and nasty bugs. > >> > >>Trying to provide this same behavior with the Java based front end in Unix > >>was a serious complication and combined with early problems with the Java > >>use of shared libraries drove the decision to have the Java front end > >>communicate with a separate J Engine through sockets. With 601 we wanted > >>to > >>move the Java front end to use the more direct and far more efficient J > >>Engine as a shared library, but this was far easier if the dispatch of > >>messages while J was in execution was abandoned. > >> > >>These changes mean that the more common GUI applications where the J > >>Engine > >>runs for only a short time (several seconds) are simpler, faster, more > >>reliable, and more portable. > >> > >>But those benefits have the drawback that applications like yours (where > >>there is GUI combined wth very long running J Engine sentences) suffer. > >> > >>Possibly an acceptable crude workaround for your current situation is to > >>mark the form with the status line with ptop so that it can't get > >>covered/uncovered (which won't get repainted properly until the J Engine > >>goes idle). > >> > >>If that doesn't work because the form is big and takes up too much screen > >>space with ptop, then you could move the status line to another form and > >>make it ptop. > >> > >>The long term solution is to move the long running computation to a > >>separate > >>thread or process. Starting from scratch this is probably the better and > >>easier way to build the app. But as a conversion it can be very nasty. The > >>idea is to break the app in two parts with clean lines between them. One > >>part does the computation and has very little user interface. The other > >>part > >>has all the GUI and stays responsive. > >> > >>----- Original Message ----- > >>From: "Henry Rich" <HenryHRich at nc.rr.com> > >>To: "'Beta forum'" <beta at jsoftware.com> > >>Sent: Thursday, January 19, 2006 6:23 PM > >>Subject: [Jbeta] Tardy graphics > >> > >> > >>>I have an application that keeps a big form displayed, the last line > >>> of which is a static control that I use as a status line. When the > >>> program goes into a long computation, every few seconds it updates the > >>> status line. I use wd 'tnomsgs 1'. > >>> > >>> In 5.04, the status line was drawn whenever I wrote to it. In 6.01, > >>> the behavior is more complex and less satisfactory: > >>> > >>> Generally, I don't see the status lines as they are written by the > >>> program. > >>> The program writes the form first thing, and then immediately launches > >>> an Internet Explorer window that covers the form. I immediately > >>> minimize the IE windows (by hand), exposing the form; but the form is > >>> all white, as if it has not been drawn. Meanwhile the program is > >>> displaying > >>> status, but I don't see it. > >>> > >>> In one case I had the form partially covered by another window, and when > >>> I minimized the covering window the underlying form appeared; but then > >>> in a moment the uncovered pixels vanished, replaced by white, just where > >>> the > >>> previously-covering window had been. > >>> > >>> > >>> > >>> Anyway, what I want is to have my status show up, something that used to > >>> happen automatically. Is there somthing like pshow'' that I can do, or > >>> does the J code need to change? > >>> > >>> Henry Rich __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
