On Fri, May 8, 2015 at 11:16 AM, Igor Stasenko <[email protected]> wrote:
> > > On 8 May 2015 at 20:00, Eliot Miranda <[email protected]> wrote: > >> >> >> 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. >> >> > what if i want to log to stdout.. why i need morphic UI element? > I've said my piece. You're making me laugh. Keep digging. > Look, understand me wrong not. ;) > I am not against having a UI element that showing the contents of > transcript (or any other stream, why not?) and updates it as soon as > possible (or as often as users see fit). > Such element is indeed quite useful and quite needed.. > What i am against is putting equality sign between transcript and such UI > element. > It is two different things, two different concerns. That's it. > > >> >> >>> 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 >> > > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot
