On Sun, May 10, 2015 at 12:35 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
Hi Eliot, Just to let you know I've been contemplating this. It sounds a good idea, but I've been too tired the past few nights to dig into it further. Also l like Cuis' Transcript for being extremely self contained and so I guess harder to break accidentally, but it was missing editing and highlighting. So I was waiting to see if there were more opinions arising from that. cheers -ben
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