On Fri, May 8, 2015 at 9: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. > 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. > 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
