What Stef means is that ideally, we should no strive to not have code like: "Transcript show: 'my event'". Instead, we should only log events (ideally, concrete classes like MyEvent) and if we want to see the textual representation of this, we just plug a Transcript interface to the logger.
Cheers, Doru On Fri, May 15, 2015 at 4:27 AM, Ben Coman <[email protected]> wrote: > >> >> >> 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 <[email protected]> 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 > > > > -- www.tudorgirba.com "Every thing has its own flow"
