Hi Ben,

On Sat, May 9, 2015 at 8:18 AM, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

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.��

3. Thinking further on this, I suppose the main issue from the original example is that its running in the UI thread.�� In this case I guess calling #changed: and #refreshWorld is okay (there have been no problems in Squeak).�� So in ThreadSafe>>endEntry we could check to see if we are in the UI thread and only in that case issue #changed:. �� So only the "user interactive" workspace will see the "slow" behaviour (which any is too fast for a human to notice), and forked processes will not be slowed.

So what about doing something such as remembering the last time the transcript updated the UI, and a) not allowing #changed to update the UI if it has been less than x milliseconds since it was last updated, and b) scheduling a deferred ui update when #changed is filtered-out in this way and c) cancelling the deferred ui update if another transcript update occurs before the deferred update is processed.

��

cheers -ben��

��

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 -->��12749ms

on Pharo 50029 --> 2ms

This 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 interactivity

Which 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.

For which I see two solutions:

�� 1. Next to the doIt menu item add a forkIt menu item -- so its optional, but not the default

�� 2. Have a Preference that enables Transcript>>nextPut: to call #changed:

Is this the entire solution space?��

See (3.) above.

4. Run Workspaces in their own thread per VW (but that already got knocked down)

��

Are there not ways of engineering the transcript to update at, say, 10Hz?��

Can the transcript not be made to render changes much faster?��

Still thinking about these.

��

I see terminals with performance thousands of times faster than the transcript that still display output immediately.�� I don't understand why the Squeak transcript is so slow.�� That's a bug also.

��

��

The first I think could be useful anyway, not having to do a cumbersome coded fork. This would also provide a measure of documentation and discoverability.�� There might be a submenu for forking at the different user priorities.

For the second, it would be pragmatic to do what we can to facilitate VM development on Pharo.�� The preference can describe how it might adverse affect multithreaded applications.

cheers -ben

--

best,

Eliot