If there are any experts here I beg you to take a look. This is really impacting ,y productivity with VM development. I lose ~ 30seconds on almost every proceed in the debugger and I'm spending most of my time there-in simulating ARM execution right now. This is really painful. The ARM JIT and hence much faster Squeak on RPi and Android will arrive all the sooner if this is fixed.

AdvThanksance

On Fri, Mar 27, 2015 at 10:31 AM, Tobias Pape Das.Linux@gmx.de wrote:

On 27.03.2015, at 17:47, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi All, Hi Bert,

a while ago I complained about extremely slow display update

following proceed in the debugger. I can now confirm that it is nothing to do with the debugger simulating code and is simply the system being out of the defer updates state. Are there any fixes for this yet? Ah... I see a reply from Tobias, maybe all I need to do is update ;-)

Sadly, no. I have next to no knowledge of that part of Squeak.

Best -Tobias

On Fri, Mar 27, 2015 at 2:37 PM, Levente Uzonyi leves@elte.hu wrote:

Does it help if you revert WorldState >> interCyclePause: to its previous version (al 7/31/2007 16:12)?

No :(. But that's at least information.

Levente

On Fri, 27 Mar 2015, Eliot Miranda wrote:

If there are any experts here I beg you to take a look. This is really

...

impacting ,y productivity with VM development. I lose ~ 30seconds on almost every proceed in the debugger and I'm spending most of my time there-in simulating ARM execution right now. This is really painful. The ARM JIT and hence much faster Squeak on RPi and Android will arrive all the sooner if this is fixed. AdvThanksance

On Fri, Mar 27, 2015 at 10:31 AM, Tobias Pape Das.Linux@gmx.de wrote:

  On 27.03.2015, at 17:47, Eliot Miranda <eliot.miranda@gmail.com>

wrote:

  > Hi All, Hi Bert,
  >
  >     a while ago I complained about extremely slow display update

following proceed in the debugger. I can now confirm that it is nothing to do with the debugger simulating code and is simply the system being out of the defer updates state. Are there any fixes for this yet? Ah... I see a reply from Tobias, maybe all I need to do is update ;-)

  Sadly, no.
  I have next to no knowledge of that part of Squeak.

  Best
          -Tobias

-- best,Eliot

Hi Marcel,

On Sat, Mar 28, 2015 at 9:49 AM, Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de> wrote:

I will try to debug it if I can reproduce it. Trying "self halt" in a workspace followed by a proceed in the debugger did not make my image slow.

So, how to reproduce that bug?

Try and create *lots* of large overlapping windows, including a transcript. Then write some code that writes something to the transcript and put a halt in it. Then proceed. That seems close to what I'm doing. HTH and thanks for taking a look!

I fixed something: http://forum.world.st/The-Trunk-Morphic-mt-793-mcz-td4816096.html

There was the possibility, that two UI processes were running after proceed, which may have caused the slow display update.

Now, it's more like the MVC-version (#mvcResumeProcess:) of resuming the process, which first makes the redraw and them resumes the interrupted process.

Eliot, does this work for you?

Best, Marcel

-- View this message in context: http://forum.world.st/slow-display-update-on-debugger-proceed-tp4815619p4816... Sent from the Squeak - Dev mailing list archive at Nabble.com.