On 5/10/15, Sven Van Caekenberghe <[email protected]> wrote: > >> 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! +1
>> basically… we need a good log console (if it is a transcript or not, is >> another discussion) :) +1 As an independent pluggable package because not everybody does VM development all the time. There might be several of them focusing on different needs. And there are already libraries claiming to be loggers. Might be used as a start. > 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 >>> >> > > >
