On Sun, May 10, 2015 at 12:35 AM, Eliot Miranda <[email protected]> wrote:
> Hi Ben, > > On Sat, May 9, 2015 at 8:18 AM, Ben Coman <[email protected]> wrote: > >> >> >> On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <[email protected]> >> wrote: >> >>> >>> >>> On Sat, May 9, 2015 at 7:09 AM, Ben Coman <[email protected]> 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 >
