On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil.�� There are too many assumptions throughout the system that the UI is single threaded.�� Can anyone advise me that is not a proper belief?Then that implies that a Transcript implementation where #nextPut: direct calls #changed:is not appropriate for use with multi-threaded applications.�� In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. ��(This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.I think the point about efficiency is significant. The following example...�� �� ��Time millisecondsToRun: [ 1000 timesRepeat: ��[ Transcript show: 'x' ] ]on Squeak 4.5 -->��12749mson Pharo 50029 --> 2msThis better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code.�� I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.��So we have two mutually exclusive cases:* better interactivity, poorer system performance* faster system performance, worse interactivityWhich of these is broken depends on your viewpoint.Something that runs fast but is incorrect is still incorrect.�� The fact that the transcript doesn't output until a world step is possible is a bug.�� It forces programs that use the transcript to be rewritten in order to see transcript output.