On Sat, May 9, 2015 at 12:21 AM, Alain Rastoul <[email protected]> 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 > > >
