May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> From my limited experience bug hunting, calling #changed: from a thread >> other than the UI thread is a source of evil. >> > 3. Thinking further on this, I suppose the main issue from the original example is that its running in the UI thread. In this case I guess calling #changed: and #refreshWorld is okay (there have been no problems in Squeak). So in ThreadSafe>>endEntry we could check to see if we are in the UI thread and only in that case issue #changed:. So only the "user interactive" workspace will see the "slow" behaviour (which any is too fast for a human to notice), and forked processes will not be slowed. cheers -ben > There are too many assumptions throughout the system that the UI is single >> threaded. Can anyone advise me that is not a proper belief? >> >> Then that implies that a Transcript implementation where #nextPut: direct >> calls #changed: >> is not appropriate for use with multi-threaded applications. In Pharo, >> #changed: is only called from #stepGlobal, which is called from >> doOneCycle:. (This came about as a last minute bug fix before Pharo 3 >> release and maybe could use some cleanup. >> >> Separating the UI from Transcript into its own viewer might be a good >> idea, but actually it would not solve Stef's case since his code would >> still be running in the UI thread -- unless the viewer ran in another >> thread, which would have its own complexities. >> >> I think the point about efficiency is significant. The following >> example... >> Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' >> ] ] >> on Squeak 4.5 --> 12749ms >> on Pharo 50029 --> 2ms >> >> This better performance helped me a lot trying to understand the high >> priority timerEventLoop being able to indiscriminately scatter Transcript >> tracing through that code. I believe its also probably beneficial for >> working with externally triggered semaphores and timing sensitive race >> conditions. >> >> So we have two mutually exclusive cases: >> * better interactivity, poorer system performance >> * faster system performance, worse interactivity >> >> Which of these is broken depends on your viewpoint. >> > > Something that runs fast but is incorrect is still incorrect. The fact > that the transcript doesn't output until a world step is possible is a > bug. It forces programs that use the transcript to be rewritten in order > to see transcript output. > > >> For which I see two solutions: >> 1. Next to the doIt menu item add a forkIt menu item -- so its >> optional, but not the default >> 2. Have a Preference that enables Transcript>>nextPut: to call #changed: >> > > Is this the entire solution space? > See (3.) above. 4. Run Workspaces in their own thread per VW (but that already got knocked down) > Are there not ways of engineering the transcript to update at, say, 10Hz? > Can the transcript not be made to render changes much faster? > Still thinking about these. > I see terminals with performance thousands of times faster than the > transcript that still display output immediately. I don't understand why > the Squeak transcript is so slow. That's a bug also. > > > >> >> The first I think could be useful anyway, not having to do a cumbersome >> coded fork. This would also provide a measure of documentation and >> discoverability. There might be a submenu for forking at the different >> user priorities. >> >> For the second, it would be pragmatic to do what we can to facilitate VM >> development on Pharo. The preference can describe how it might adverse >> affect multithreaded applications. >> >> cheers -ben >> >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sat, May 9, 2015 at 11:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 09 May 2015, at 16:41, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > > > On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc(a)openinworld.com> wrote: > > From my limited experience bug hunting, calling #changed: from a thread > other than the UI thread is a source of evil. There are too many > assumptions throughout the system that the UI is single threaded. Can > anyone advise me that is not a proper belief? > > > > Then that implies that a Transcript implementation where #nextPut: > direct calls #changed: > > is not appropriate for use with multi-threaded applications. In Pharo, > #changed: is only called from #stepGlobal, which is called from > doOneCycle:. (This came about as a last minute bug fix before Pharo 3 > release and maybe could use some cleanup. > > > > Separating the UI from Transcript into its own viewer might be a good > idea, but actually it would not solve Stef's case since his code would > still be running in the UI thread -- unless the viewer ran in another > thread, which would have its own complexities. > > > > I think the point about efficiency is significant. The following > example... > > Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' > ] ] > > on Squeak 4.5 --> 12749ms > > on Pharo 50029 --> 2ms > > > > As a point of comparison, on VW 8.0 --> 43817ms > > and so you might guess, VW 8.0 outputs each 'x' immediately. > > cheers -ben > > I am not sure, but in VW it looks like each Workspace (Window) is > (executing its Doit) in a separate thread. > Nice pick up. I checked and for each opened workspace their Process Monitor shows another process labelled "Workspace." Executing the example from the original post in a Workspace shows that Workspace waiting on the delay. So this aligns with one of the suggestions above. cheers -ben

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

> On 09 May 2015, at 16:57, phil(a)highoctane.be wrote: > > I wonder why a couple of stream methods are not in. This whole thread started with a discussion about a multi-threading issue. What is wrong with the API exactly ? Writestream has way too many methods already, do people really want them all ? > Also the idea of having something we can connect to observe a stream is really interesting. yes > A single transcript is a bit too little for my tastes. yes > I often write to several files and have tail -f on them in several windows in tmux. yes > Would be nice to have that in Pharo. yes > Phil > > Le 9 mai 2015 14:29, "stepharo" <stepharo(a)free.fr> a Ã©crit : > > > > Eliot > > > > I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. > > It was terrible. > > > > Stef > > > > > > Le 8/5/15 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) > >> > >> On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > >> > >>> Le 08/05/2015 11:34, stepharo a Ã©crit : > >>>> > >>>> Hi guys > >>>> > >>>> the Transcript in Pharo is that it's not asynchronous so I can't use it > >>>> in VM development to show the current progress of the simulation. For > >>>> example: > >>>> 1 to: 100 do: [ :i | > >>>> 0.1 seconds asDelay wait. > >>>> Transcript show: 'x'. ] > >>>> => on Squeak, this shows a x every 0.1 second in the Transcript > >>>> => on Pharo, nothing happens during 10 seconds then all the x are shown. > >>>> > >>>> https://pharo.fogbugz.com/default.asp?15515 > >>> > >>> Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem. > >>> > >>> Probably in squeak, in Transcript this is done somewhere under the hood. > >>> > >>> via dependents ? > >>> > >>> TranscriptStream>>endEndtry > >>> "Display all the characters since the last endEntry, and reset the stream" > >>> self semaphore critical:[ > >>> self changed: #appendEntry. > >>> self reset. > >>> ]. > >>> > >>> Object>>changed: aParameter > >>> self dependents do: [:aDependent | aDependent update: aParameter] > >>> > >>> And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows). > >>> > >>> > >>> -- > >>> Regards, > >>> > >>> Alain > >>> > >>> > >> > >> > > > >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

> On 09 May 2015, at 16:41, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc(a)openinworld.com> wrote: > From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief? > > Then that implies that a Transcript implementation where #nextPut: direct calls #changed: > is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup. > > Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities. > > I think the point about efficiency is significant. The following example... > Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] > on Squeak 4.5 --> 12749ms > on Pharo 50029 --> 2ms > > As a point of comparison, on VW 8.0 --> 43817ms > and so you might guess, VW 8.0 outputs each 'x' immediately. > cheers -ben I am not sure, but in VW it looks like each Workspace (Window) is (executing its Doit) in a separate thread. In any case, their abstraction, TextCollector is nicer.

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by phil＠highoctane.be

I wonder why a couple of stream methods are not in. Also the idea of having something we can connect to observe a stream is really interesting. A single transcript is a bit too little for my tastes. I often write to several files and have tail -f on them in several windows in tmux. Would be nice to have that in Pharo. Phil Le 9 mai 2015 14:29, "stepharo" <stepharo(a)free.fr> a Ã©crit : > > Eliot > > I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. > It was terrible. > > Stef > > > Le 8/5/15 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) >> >> On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> >>> Le 08/05/2015 11:34, stepharo a Ã©crit : >>>> >>>> Hi guys >>>> >>>> the Transcript in Pharo is that it's not asynchronous so I can't use it >>>> in VM development to show the current progress of the simulation. For >>>> example: >>>> 1 to: 100 do: [ :i | >>>> 0.1 seconds asDelay wait. >>>> Transcript show: 'x'. ] >>>> => on Squeak, this shows a x every 0.1 second in the Transcript >>>> => on Pharo, nothing happens during 10 seconds then all the x are shown. >>>> >>>> https://pharo.fogbugz.com/default.asp?15515 >>> >>> Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem. >>> >>> Probably in squeak, in Transcript this is done somewhere under the hood. >>> >>> via dependents ? >>> >>> TranscriptStream>>endEndtry >>> "Display all the characters since the last endEntry, and reset the stream" >>> self semaphore critical:[ >>> self changed: #appendEntry. >>> self reset. >>> ]. >>> >>> Object>>changed: aParameter >>> self dependents do: [:aDependent | aDependent update: aParameter] >>> >>> And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows). >>> >>> >>> -- >>> Regards, >>> >>> Alain >>> >>> >> >> > >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc(a)openinworld.com> wrote: > From my limited experience bug hunting, calling #changed: from a thread > other than the UI thread is a source of evil. There are too many > assumptions throughout the system that the UI is single threaded. Can > anyone advise me that is not a proper belief? > > Then that implies that a Transcript implementation where #nextPut: direct > calls #changed: > is not appropriate for use with multi-threaded applications. In Pharo, > #changed: is only called from #stepGlobal, which is called from > doOneCycle:. (This came about as a last minute bug fix before Pharo 3 > release and maybe could use some cleanup. > > Separating the UI from Transcript into its own viewer might be a good > idea, but actually it would not solve Stef's case since his code would > still be running in the UI thread -- unless the viewer ran in another > thread, which would have its own complexities. > > I think the point about efficiency is significant. The following example... > Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] > ] > on Squeak 4.5 --> 12749ms > on Pharo 50029 --> 2ms > As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)openinworld.com> wrote: > From my limited experience bug hunting, calling #changed: from a thread > other than the UI thread is a source of evil. There are too many > assumptions throughout the system that the UI is single threaded. Can > anyone advise me that is not a proper belief? > > Then that implies that a Transcript implementation where #nextPut: direct > calls #changed: > is not appropriate for use with multi-threaded applications. In Pharo, > #changed: is only called from #stepGlobal, which is called from > doOneCycle:. (This came about as a last minute bug fix before Pharo 3 > release and maybe could use some cleanup. > > Separating the UI from Transcript into its own viewer might be a good > idea, but actually it would not solve Stef's case since his code would > still be running in the UI thread -- unless the viewer ran in another > thread, which would have its own complexities. > > I think the point about efficiency is significant. The following example... > Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] > ] > on Squeak 4.5 --> 12749ms > on Pharo 50029 --> 2ms > > This better performance helped me a lot trying to understand the high > priority timerEventLoop being able to indiscriminately scatter Transcript > tracing through that code. I believe its also probably beneficial for > working with externally triggered semaphores and timing sensitive race > conditions. > > So we have two mutually exclusive cases: > * better interactivity, poorer system performance > * faster system performance, worse interactivity > > Which of these is broken depends on your viewpoint. > Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output. > For which I see two solutions: > 1. Next to the doIt menu item add a forkIt menu item -- so its optional, > but not the default > 2. Have a Preference that enables Transcript>>nextPut: to call #changed: > Is this the entire solution space? Are there not ways of engineering the transcript to update at, say, 10Hz? Can the transcript not be made to render changes much faster? I see terminals with performance thousands of times faster than the transcript that still display output immediately. I don't understand why the Squeak transcript is so slow. That's a bug also. > > The first I think could be useful anyway, not having to do a cumbersome > coded fork. This would also provide a measure of documentation and > discoverability. There might be a submenu for forking at the different > user priorities. > > For the second, it would be pragmatic to do what we can to facilitate VM > development on Pharo. The preference can describe how it might adverse > affect multithreaded applications. > > cheers -ben > > > On Sat, May 9, 2015 at 3:12 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> > On 08 May 2015, at 21:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> > >> > >> > >> > 2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> > >> > >> > On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> > >> > >> > On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat(a)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. >> >> We also have NonInteractiveTranscript which I use a lot ! >> >> > Only the Transcript has a different behavior, which is not compatible >> with the use cases of VM development. >> >> IMHO this is a discussion about efficiency, the price you are willing to >> pay: the old system was slow because it tries to update for each #endEntry, >> the new system is way faster, but does not update if you block the UI >> thread. (There are also correctness issues, the red screen of death). >> >> It would not be too hard to image this being an option/setting. >> >> The 'better' design would be to have a stream viewer thing that is clever >> enough to batch updates if they come fast and only draw them when needed. >> >> > 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, Eliot

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Sat, May 9, 2015 at 5:37 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > Eliot I do not understand why you are reacting like that. Our goal is not > to make the live of people worse. All the efforts we > do in Pharo is to get better. > Reacting like what? I am trying to establish that the transcript is broken and needs fixing. Do you agree or not? If you don't agree then fine, ClÃ©ment will continue to develop the VM in Squeak, and I'll always be confused about the Pharo community's ability to discuss technical issues. If you do agree, then why not plan to fix it? If instead you don't want to discuss the technical issue and instead see this as some kind of emotional attack then I'm sorry but that's completely dysfuncitonal. People make mistakes. Communities bake bad decisions. These things happen. But mature people and functional communities can recognize (you notice I didn't say admit, no one wants to ridicule people for their mistakes, I make serious mistakes continuously) their mistakes and rectify them. I am /not/ attacking the community, I am /not/ saying that Pharo is not trying to improve things, I am /not/ saying the old transcript was the most perfect piece of software ever, I am saying that the current behaviour and api of the transcript is *broken*. It needs to be a) compatible with WriteStream, and b) needs to display its output as soon as it is sent flush. Do you disagree? > I changed the transcript because when I started to work on concurrent > programming chapters then the transcript was simply useless. > Now I would like to know how we can improve the solution and this is why I > sent this mail. > But apparently I should not have. :( > > I did not send it to receive your kind of emails. I'm convinced you can do > better. I do not know what you mean about doctrine. > Pharo objectives is to bring money in Smalltalk and to build better tools > and infrastructure. > > Stef > > > -- best, Eliot

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Sat, May 9, 2015 at 5:29 AM, stepharo <stepharo(a)free.fr> wrote: > Eliot > > I changed the transcript because it is not thread safe so I could use it > at all to explain concurrent programming output. > It was terrible. > I don't see what that has to do with my usability point. The transcript was a) a stream b) something that displayed its output immediately Those two features are essential. If you change the transcript so that it no longer has those features you have broken it. Igor waffled on about internals, the desire to separate the UI from the stream, a point that has nothing to do with the utility of the transcript. No you're going on about its thread-safety. But no one is addressing my point. And you have ClÃ©ment telling you that he cannot develop the VM in Pharo because the transcript is broken, and you have others proposing various potentially error-prone work-arounds to get around the fact that the transcript is broken. Why won't anyone stand up and say yes, the transcript is broken and yes we will fix it? This is dysfunctional. > Stef > > > Le 8/5/15 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) >> >> On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> >> Le 08/05/2015 11:34, stepharo a Ã©crit : >>> >>>> Hi guys >>>> >>>> the Transcript in Pharo is that it's not asynchronous so I can't use it >>>> in VM development to show the current progress of the simulation. For >>>> example: >>>> 1 to: 100 do: [ :i | >>>> 0.1 seconds asDelay wait. >>>> Transcript show: 'x'. ] >>>> => on Squeak, this shows a x every 0.1 second in the Transcript >>>> => on Pharo, nothing happens during 10 seconds then all the x are shown. >>>> >>>> https://pharo.fogbugz.com/default.asp?15515 >>>> >>> Yes, as do it are evaluated in the World morphic process, running in a >>> forked process or sending World doOneCycle in the loop solve the problem. >>> >>> Probably in squeak, in Transcript this is done somewhere under the hood. >>> >>> via dependents ? >>> >>> TranscriptStream>>endEndtry >>> "Display all the characters since the last endEntry, and reset the >>> stream" >>> self semaphore critical:[ >>> self changed: #appendEntry. >>> self reset. >>> ]. >>> >>> Object>>changed: aParameter >>> self dependents do: [:aDependent | aDependent update: aParameter] >>> >>> And probably not doOnecycle since you cannot do anything else during >>> execution (clicking or moving windows). >>> >>> >>> -- >>> Regards, >>> >>> Alain >>> >>> >>> >> >> > > -- best, Eliot

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

>From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief? Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup. Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities. I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions. So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity Which of these is broken depends on your viewpoint. For which I see two solutions: 1. Next to the doIt menu item add a forkIt menu item -- so its optional, but not the default 2. Have a Preference that enables Transcript>>nextPut: to call #changed: The first I think could be useful anyway, not having to do a cumbersome coded fork. This would also provide a measure of documentation and discoverability. There might be a submenu for forking at the different user priorities. For the second, it would be pragmatic to do what we can to facilitate VM development on Pharo. The preference can describe how it might adverse affect multithreaded applications. cheers -ben On Sat, May 9, 2015 at 3:12 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 08 May 2015, at 21:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > > > > > 2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > > > > > On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat(a)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. > > We also have NonInteractiveTranscript which I use a lot ! > > > Only the Transcript has a different behavior, which is not compatible > with the use cases of VM development. > > IMHO this is a discussion about efficiency, the price you are willing to > pay: the old system was slow because it tries to update for each #endEntry, > the new system is way faster, but does not update if you block the UI > thread. (There are also correctness issues, the red screen of death). > > It would not be too hard to image this being an option/setting. > > The 'better' design would be to have a stream viewer thing that is clever > enough to batch updates if they come fast and only draw them when needed. > > > 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 > > >

May 9, 2015