> On 10 May 2015, at 10:36, Esteban Lorenzano <[email protected]> wrote: > > +1 > > let’s recapitulate: > > requirement is > - fast > - editable > - polymorphic with WriteStream > - and immediate to screen > from our perspective (pharo), it has to be also > - thread safe > - well designed. > > our constraints are: > - bad design of transcripts > - super naive implementation of text editors (this is, IMO, the reason why > transcripts are so slow: if you redraw all the window interior each time you > add a line, you are screw)
Good summary! > basically… we need a good log console (if it is a transcript or not, is > another discussion) :) Yes, that is really all there is to it > So… who proposes a solution? > > Esteban > > >> On 10 May 2015, at 00:40, Yuriy Tymchuk <[email protected]> wrote: >> >> 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]> 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]> 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 >> >
