On Fri, May 8, 2015 at 10:52 AM, Igor Stasenko <[email protected]> wrote:
> > > On 8 May 2015 at 19:39, Eliot Miranda <[email protected]> wrote: > >> >> >> On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <[email protected]> >> wrote: >> >>> >>> >>> On 8 May 2015 at 19:22, Eliot Miranda <[email protected]> wrote: >>> >>>> >>>> >>>> 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. >>>> >>>> >>> 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? >> >> > Transcript is not an UI element, it is a stream. Period. > Ah, a write-only invisible transcript. Riiiight. Really useful to log output to somewhere no one can see it. Riiight. No, Igor, the Transcript is a UI element and a stream. It is a place to log textual output where the programmer can see it. It is Smalltalk's standard output console. If one ants a stream which will record output one can use a file. If one wants to see it in real time, one uses a transcript. > From that perspective, is it *not* broken in Pharo and works well. > You can write to transcript and everything you written to it is not lost > and recorded.. > to be later piped wherever used wants it to. > I repeat again, Transcript is *not* an UI element simply because it works > even if there's no any transcript window open. > From that perspective the 'flush' command issued cannot be interpreted as > a 'do whatever it takes and deliver immediately my contents to the screen', > because obviously there may be no any screen nor window.. > So, the 'flush' behavior is more like a soft hint, that can be completely > ignored (making users mad :) ) rather than strict command. > > So, forcing updates to the screen (even if you not really neeed it), is a > separate > issue, and as to me, has little to do with transcript, because it is more > general problem of being able to update screen at the moment you want, > not at the moment, when a system designed to do that. > > >> >>> >>>> >>>>> 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 >> > > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot
