For me saying that internals are not important as long as transcript does what is expected from it, is like saying that Parser being a subclass of Scanner and Compiler being as subclass of Parser is ok as long as it compiles source code. We already had that and it was bad.
On the other hand it’s obvious that we don’t have enough resources to rewrite Pharo from scratch and we cannot leave issues as they are just because we cannot solve them perfectly now. I would say that Igor is correct saying that we need a better architecture, and Stef and Eliot are correct saying that we need tools that fulfill users’ needs. And we have to say: “ok now we hack this around, but we have to do this the right way one day”. Is anyone familiar with same-css[1] concept? Uko P.S. maybe my 2 cents are useless, but all the fight around this discussion is really strange for me. In Ukraine we have a saying that it’s better to be healthy and poor than sick and rich. Now I use to say that it’s better to be healthy and rich than sick and poor. And all the fight here was if it’s better to be healthy or rich. Definitely it’s better to be both, we cannot do that instantly but we can set goals and milestones, and find the optimal strategy. [1]: http://csswizardry.com/2013/04/shame-css/ > On 09 May 2015, at 16:17, Eliot Miranda <[email protected]> wrote: > > > > On Sat, May 9, 2015 at 5:29 AM, stepharo <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > <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
