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