On Sat, May 9, 2015 at 7:09 AM, Ben Coman <[email protected]> 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 <[email protected]> > wrote: > >> >> > On 08 May 2015, at 21:00, Clément Bera <[email protected]> wrote: >> > >> > >> > >> > 2015-05-08 19:39 GMT+02:00 Eliot Miranda <[email protected]>: >> > >> > >> > 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? >> > >> > 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
