[UI] Re: Transcript>>show: slowness.

Bert Freudenberg bert at freudenbergs.de
Sun Sep 9 20:17:39 UTC 2007


On Sep 9, 2007, at 22:05 , Igor Stasenko wrote:

> On 09/09/2007, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>> On Sep 9, 2007, at 21:31 , Igor Stasenko wrote:
>>
>>> On 09/09/2007, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> On Sep 9, 2007, at 15:11 , Igor Stasenko wrote:
>>>>
>>>>> I want to ask, if someone knows, why transcript (or maybe
>>>>> underlaying
>>>>> morphs) designed in such manner, that it forcibly updates  
>>>>> itself on
>>>>> screen at each #show: message sent.
>>>>
>>>> So that you can see log entries even if you are in a longer
>>>> computation that blocks the UI.
>>>>
>>> Just read your sentence more carefully! :)
>>> "computation _blocks UI_". Blocks means: no input , no output!
>>> Since transcript window is the part of UI, so why you think it  
>>> should
>>> make an exception?
>>
>> Because it's useful, maybe? Who cares about Transcript performance if
>> it is "pure" but useless?
>>
> I care, because i want to trace some stuff in my drawing code. But i
> can't do that because each call to #show makes transcript window being
> redrawn.

Right. Do not use Transcript for that. "'some string' display" works  
nicely. You could even write your own Transcript view for such uses.

> And also, if you want your computation to not block UI, you can  
> always do:
> [ myStuff doSomething ] fork.
>
> Take a look, how MC works. Do you find it convenient that during
> updating/dowloading and installing package from net you can't do
> anything because all UI is blocked?

You realize this is entirely besides the point of this discussion?

- Bert -




More information about the UI mailing list