Werner Kassens wrote:
Hi,
On 09/06/2014 03:35 PM, Ben Coman wrote:
Just to be clear, by "did some calculations for an hour" do you mean the Image basically locked up during the calculation, and the mouse clicks were queued until the calculation ended?
exactly, after the calculation different windows spring into the foreground, if i redo that. the strange thing though is, that the errormessages came during the calculation and although (they added up fast) i did not really look at them (i just cklicked them away, after having interrupted the program) in the end they originated from the browser.
Anyhow, there are two general approaches I am familiar with. 1. Add " Processor yield " within your calculation loop. 2. Run your calculation at a priority lower than the UI. For example, " result := nil. calculationProcess := [ result := self myCalculation ] forkAt: Processor userBackgroundPriority " , then periodically test for " result ~= nil " , maybe from a "step" method in your own subclass of some Morph.
and what do i do after 'result ~= nil' ? <stupid grin>
Sorry, I can't tell across email if that <stupid grin> is tongue-in-cheek since you know exactly what to do, or you are looking for advice :) It depends... How would you deal with the result of your calculation (assuming you didn't fork it)? In very general terms you'd have MyMorph>>step (result ~= nil) ifTrue: [ "do stuff to update my 'StringMorph' submorphs with result data I now have" "or do stuff to write results to disk or database, and display 'FINISHED', and sound a beep" ]
and what is the disadvantage of the simple first solution, i have to admit i never looked at these fork things? werner
I'm not sure if there is any practical disadvantage**. Again, it depends... on how tight your loops are, and exactly where you put the "Processor yeilds". You'd need to suck-it-and-see. But speaking generally, you calculation is still competing with the UI loop. If you yield every 100ms and you click the mouse immediately after the calculation starts, then the click will** not be seen by the UI for 100ms, so you will see some lag. There may be downsides to yielding more often**, and it may take some effort to determine cycle period of various parts of your loops to get it working smoothly, if even these remain consistent across the life and use of your application. With the second approach, any mouse click will interrupt the calculation and be handled immediately** so its likely the UI will remain more responsive. With the second approach, it is also easier to suspend and continue the calculation, if you so desired. ** These are my beliefs I've picked as I've looked into some parts of Pharo internals, but I don't know enough to be sure. Others might correct me. cheers -ben