Hi Christoph,

On Sat, Sep 19, 2020 at 1:17 PM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Eliot, these are interesting ideas! :-)
>
>
> Your pattern is cool, it reminds me a little bit of the approach we are
> using for Shout, see SHTextStyler >> #styleInBackgroundProcess:.
>
> It even more reminds me of Collection >> #do:displayingProgress:every:.
>
> And last but not least, at a fundamental level, aren't we replicating the
> usual stepping logic from WorldState here?
>

I don't think so.  What we're doing is decouplng from it.  But you could be
right.  It seems to me like an MVC/MVP pattern.  The model is changing, but
it only makes sense to change the display when the observer can represent
the model.  If one is in an animation system such as Morphic then the
observer (V or V&P)  only needs display the model when rendering the next
frame, if the model has changed.  So what we'd like is automatic filtering
or buffering of the state the odel uses to announce it has changed.  But we
don't have that.  We've just got SharedQueue.  So a poor man's solution is
to use it.

>
> In your approach, where do you process the scheduled messages? The problem
> is that we are running the simulation/execution code on the UI process. See
> this thread, too:
> http://forum.world.st/Debugging-of-other-processes-with-wait-tp5119965p5120049.html
>
> I would not use #lastDeferredUIMessage unless we can rule out that any
> other client is communicating with the WorldState. Which we, afaik, never
> can rule out since the idea of the deferred messages is that you can have
> them scheduled from any background process.
>
> It would be cool to develop some reusable logic that is applicable to
> different domains without expensive adaption. Maybe we should just add some
> static generic helper method for this?
>

Well, take a look at what I commited to inbox.  It soles the run to here
problem, but does not fix fast clicking.  So I'm just pointing you to it
because it may be useful.  I think you can focus on the problem better than
I.  But I'm here if you need to bounce ideas off me.  Thanks for your
energy here!!

> Best,
>
> Christoph
>
>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
> *Gesendet:* Samstag, 19. September 2020 21:36:57
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] Can we make computing the local variables in
> the debugger lazy?
>
> Hi Christoph,
>
> On Sat, Sep 19, 2020 at 11:57 AM Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>
>> Hi Eliot,
>>
>>
>> very nice finding once again! I #timeProfile'd the menu button action and
>> as I expected, the most expensive operation is the shout styling by the new
>> inspectors, including the decompilation of every method:
>>
>>
>>
>> <http://www.hpi.de/>
>>
>> First, when loading ShoutCore-ct.78 (Inbox), the speed doubles (but
>> probably that's rather a problem with my sources file, see the thread about
>> this commit).
>>
>> Second, we do not redraw the world while running to the selection, so we
>> do not need to update the inspectors at all. I think we could split up
>> #doStep into some #basicDoStep (which would perform the actual stepping
>> logic) + some #updateContextDuring: (which would update the stack list and
>> the inspectors), then we would need to trigger the updates only once from
>> #runToSelection:.
>> As an alternative, we could make this method a bit more complex but
>> responsive by applying the same updating logic from #runUntil.
>>
>
> Nice.  What ever is TSTTCPW :-).  But it strikes me that one way is to use
> addDeferredUIMessage:.  The only tricky thing is not creating lots of these
> unnecessarily.  But that could be done by checking if the deferred
> action queue is empty or not.  E.g.  rewrite this in doStep:
>
> self contextStackIndex > 1
> ifTrue: [self resetContext: newContext]
> ifFalse:
> [newContext == currentContext
> ifTrue: [self changed: #contentsSelection.
> self updateInspectors]
> ifFalse: [self resetContext: newContext]].
>
> as, say,
>
> self contextStackIndex > 1
> ifTrue: [self resetContext: newContext]
> ifFalse:
> [newContext == currentContext
> ifTrue: [self scheduleUIUpdate]
> ifFalse: [self resetContext: newContext]].
>
> add an inst var to hold the last deferred action, and then do something
> like
>
> Debugger>>scheduleUIUpdate
>     (lastScheduledUpdate notNil
>     and: [WorldState lastDeferredUIMessage == lastScheduledUpdate])
> ifTrue:
>         [^self].
>     lastScheduledUpdate := [self changed: #contentsSelection. self
> updateInspectors].
>     WorldState addDeferredUIMessage: lastScheduledUpdate
>
> For this we have to add the lastDeferredUIMessage accessor to all the
> relevant places, but it seems a nice pattern to me.
>
> And of course, there is no need to refresh lastScheduledUpdate.  It could
> be
>
> Debugger>>scheduleUIUpdate
>     lastScheduledUpdate ifNil: [lastScheduledUpdate := [self changed:
> #contentsSelection. self updateInspectors]].
>     WorldState lastDeferredUIMessage ~~ lastScheduledUpdate ifTrue:
>         [WorldState addDeferredUIMessage: lastScheduledUpdate]
>
> What do you think? :-)
>>
>
> What do you like?
>
>> Best,
>> Christoph
>> ------------------------------
>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>> Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
>> *Gesendet:* Samstag, 19. September 2020 20:17:12
>> *An:* The general-purpose Squeak developers list; Taeumel, Marcel
>> *Betreff:* [squeak-dev] Can we make computing the local variables in the
>> debugger lazy?
>>
>> Hi Marcel,
>>
>>     can we try and reduce the frequency at which we compute the variables
>> in the context inspector in the debugger?  It is a noticeable
>> performance hit.  I really like the user interface, but the performance hit
>> is making debugging difficult.
>>
>> As an example use this:
>>
>> | samples sineTable sound |
>> "1 second of A below middle C (220Hz). 16000 / 220 is 72.72 recurring"
>> sineTable := SoundPlayer sineTable: 73.
>> sineTable doWithIndex: "And let's not deafen anyone..."
>> [:sample :index| sineTable at: index put: sample // 4].
>> samples := SoundBuffer new: 16000.
>> 1 to: samples size by: sineTable size do:
>> [:i| samples replaceFrom: i to: (i + sineTable size - 1 min: 16000) with:
>> sineTable startingAt: 1].
>> 1 to: 146 do:
>> [:i|
>> samples at: i put: ((samples at: i) * i / 146) asInteger.
>> samples at: 16001 - i put: ((samples at: 16001 - i) * i / 146) asInteger].
>> sound := SampledSound
>> samples: samples
>> samplingRate: 16000.
>> sound := MixedSound new
>> add: sound pan: 0.25;
>> add: sound pan: 0.75;
>> yourself.
>> sound computeSamplesForSeconds: sound duration
>>
>>
>> Open a workspace in e.g. a 64-bit image prior to Tools-mt.965 (I used an
>> image containing Tools-mt.942).  Debug the above in the workspace.
>> Position the cursor at "sound computeSamplesForSeconds: sound duration"
>> and do "run to here".  It is essentially instantaneous.
>>
>> Now do the same in a contemporary trunk image.  It takes almost 6 seconds.
>>
>> I used to be able to click step as fast as I could and the system would
>> keep up with me.  Now I find that if I click too fast I can accumulate
>> excess clicks and when I stp clicking the system will continue stepping and
>> go too far.
>>
>> I don't want to lose the feedback the new variables list gives us.  But I
>> do find the performance hit tedious.  I wonder could we cache the list and
>> only update it
>> - when Morphic updates, and
>> - when the context changes?
>>
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200919/6ecce422/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 399308 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200919/6ecce422/attachment-0001.png>