On Sat, May 9, 2015 at 12:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Le 08/05/2015 16:16, Eliot Miranda a écrit :
Hi,
if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.
Eliot (phone)
Yes using World dooneCycle is bad, but forking another process not bad IMHO:
There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.
The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.
If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.
Wouldn't it be better to execute do-it (s) systematically in another process ?
This is an interesting idea. Actually if you DebugIt you already get a separate process, so always forking a separate process for DoIts could be considered more consistent. What would be the downside of doing this? cheers -ben
and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?
And to start, with a simple right-click menu option : 'Do it async' to experiment
I'd go the other way and make the forking 'DoIt' default, and while we test it out, have a backup menu item 'DoIt within system UI loop'.
(from a recent discussion, may be few problems with the inspector, but that's another point)
The Pharo philosophy is to press forward. If it forces a few UI threading issues into the light, that could be beneficial overall. Now to the Squeak/Pharo difference. Squeak does this... TranscriptStream>>show: TranscriptStream>>endEntry TranscriptStream>>changed: DependentsArray>>do: TranscriptStream>>changed: PluggableTextMorphPlus>>update: PluggableTextMorph>>update: Morph>>refreshWorld PasteUpMorph>>displayWorldSafely: First, Pharo's PluggableTextMorph>>update: does not call #refreshWorld. Second, Pharo replaced TranscriptStream with ThreadSafeTranscript. This behaviour has been present since at least build 20000 (I could not find an earlier one). Further, the fix [1] for the "Transcript red screen of death" occurring just before Pharo 3 release ensures the Transcript display is updated only once each Morphic cycle (which has the side effect of making calls to #show: faster.) [1] https://pharo.fogbugz.com/default.asp?13032 cheers -ben
I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?
-- Regards,
Alain