> > > Le 14/5/15 15:12, Alain Rastoul a écrit : > > Le 14/05/2015 02:08, J. Vuletich (mail lists) a écrit : >> >>> A port of the code to Pharo is required, as Alain and Stef have shown. >>> Besides, Cuis doesn't include support for Traits. I think your idea is >>> very good, and I hope some Pharoer (Alain?) does it. >>> >> >> Hi Juan, >> >> I tried Cuis, you did a very nice work here. >> >> About porting, I did this first raw port to allow other peoples who >> complains about pharo transcript to have a look at Cuis Trancript more >> easily. >> And apart from a small window inset problem and an initial display Form I >> probably did not get well (and/or a clip missing somewhere?), it does the >> same thing than in Cuis. >> >> May be we should wait a little so that people can say their word about it >> too and eventually/if they want/can/... investigate those two morphic >> porting issues. >> In the meanwhile, a simple "fix" in the Transcript could be done too >> (see last Ben's post) with an extra system settings. >> >> About sluggishnesh and Transcript speedup , the changes you made in Cuis, >> as seen in git commits, are a bit intrusive (DateAndTime, AbstractFont, >> Strikefont ?), I don't think I know pharo enough to report them. >> >> Also I experienced another issue that exits in Cuis too: >> >> The Transcript overwrite other morphs/windows when showing its contents >> during do-it >> >> After end of execution, the world redisplays correctly >> but not in Pharo >> >> (see attached screen shots) >> >> >> > > On Fri, May 15, 2015 at 3:18 AM, stepharo <steph...@free.fr> wrote:
> Thanks alain for checking. > I think that we can offer different implementations and let people pick > the ones they like. > My goal is to remove direct refer to Transcript from the image so that we > can plug an implementation and in particular > the merge of Doru and Norbert/Mine loggers > > Stef > I don't quite follow "remove direct refer to Transcript". Isn't "Transcript" effectively a global variable that can already be plugged with any implementation? As I've been contemplating the Transcript situation, I keep coming back to the idea that Transcript should be a client of a broader logging framework, but wondering how much complication that would to tracing VM simulation. Further, since the logging framework needs to be threadsafe, rather than using protected access to a shared datastructure, would it be good to have a separate "logging" process to consume log entry submissions from multiple threads, and pass them on to output threads (including Transcript viewer). Some possible advantages: * Eliminate complications from priority inversion ( http://en.wikipedia.org/wiki/Priority_inversion) * Minimise code that log-entry-producer-thread needs to execute/debug into -- maybe beneficial for VM simulation? * Minimises execution time in log-entry-producer-thread. cheers -ben
