> On 10 May 2015, at 13:10, stepharo <[email protected]> wrote: > > Why we cannot use the of Juan? > > > > Le 10/5/15 10:36, Esteban Lorenzano a écrit : >> +1 >> >> let’s recapitulate: >> >> requirement is >> - fast >> - editable > why do you need to edit it?
you can type in it, make do it, etc. (just like now) > >> - 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) >> >> basically… we need a good log console (if it is a transcript or not, is >> another discussion) :) >> >> So… who proposes a solution? >> >> Esteban >> >> >>> On 10 May 2015, at 00:40, Yuriy Tymchuk <[email protected] >>> <mailto:[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/ >>> <http://csswizardry.com/2013/04/shame-css/> >>>> On 09 May 2015, at 16:17, Eliot Miranda <[email protected] >>>> <mailto:[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 >>> >> >
