On 8 May 2015 at 21:00, Clément Bera <bera.clem...@gmail.com> wrote:
> > > 2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>: > >> >> >> 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? >> > > 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. > > Only the Transcript has a different behavior, which is not compatible with > the use cases of VM development. > > > The rationale was to change things in a way that: - updates on the screen should not impact heavily the performance of the system and should not happen more often than actual physical screen can update itself, not speaking about that users's cannot read text that flies at the light speed before your eyes and therefore completely useless from the usability perspective. Another rationale is that the only facility that should know how 'immediately' of 'forcibly' update the screen should be the GUI framework, and should properly expose such functionality via its own API or whatever.. but not the strangely wired and single utility (albeit quite useful), that tries to force updates on the screen disregarding everything and stalling the system, burning cpu on redrawing the screen faster than anyone can read.. -- Best regards, Igor Stasenko.
