On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguc...@gmail.com> wrote:
> > > On 8 May 2015 at 19:22, Eliot Miranda <eliot.mira...@gmail.com> wrote: > >> >> >> On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm....@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? > >> >>> 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
