From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil.�� 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.

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:

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

On Sat, May 9, 2015 at 3:12 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

> On 08 May 2015, at 21:00, Cl��ment Bera <bera.clement@gmail.com> wrote:
>
>
>
> 2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
>
>
> On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua@gmail.com> wrote:
>
>
> On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
> On Fri, May 8, 2015 at 9: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.
>
> Why?�� Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?
>
>
> 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 ?
>
> I find this faintly absurd.�� This is, in the English phrase, the tail wagging the dog.�� You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself.�� So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system?�� I think that's a little mad.
>
>
> True.. but this is only highlights how deeply broken the overall system around UI are.
> Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ?
> I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning.
>
> I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)
>
> I still don't hear any rationale for the transcript not updating itself when it does flush/endEntry:.�� I still don't hear any rationale for the morphic transcript�� behaving differently to a stdout transcript.�� In that case, it only makes sense to fix the transcript, right?
>
> That was my original point. I would like a tool, as used to be the Transcript, that has the same behavior than the stdout transcript but shows the stream in the image instead of the command line.
>
> In Pharo stdout is not broken. It works fine and I use it often. You can start Pharo from the command line and try the do-it:
>
> 1 to: 100 do: [ :i |
>�� �� ��0.1 seconds asDelay wait.
>�� �� ��FileStream stdout << 'x'. ]
>
> x is displayed every 100 ms on the command line.

We also have NonInteractiveTranscript which I use a lot !

> Only the Transcript has a different behavior, which is not compatible with the use cases of VM development.

IMHO this is a discussion about efficiency, the price you are willing to pay: the old system was slow because it tries to update for each #endEntry, the new system is way faster, but does not update if you block the UI thread. (There are also correctness issues, the red screen of death).

It would not be too hard to image this being an option/setting.

The 'better' design would be to have a stream viewer thing that is clever enough to batch updates if they come fast and only draw them when needed.

> 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
> (from a recent discussion, may be few problems with the inspector,
> but that's another point)
>
> I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?
>
>
>
> --
> Regards,
>
> Alain
>
>
>
>
>
> --
> best,
> Eliot
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>
> --
> best,
> Eliot