Pressed save too early. The infrastructures for doing that exist already in SystemLogger and Beacon, and we will merge these two and produce one common logging engine.
However, one challenge that came out of the description of Clement is to show a partial representation of an event before the full event is completed. For example, one issue is to see the printing of a compiled method while it is being compiled. In a regular case, you would model the event to be the MethodCompiledSignal that holds the string or the object, but this would only be available after the method was compiled. As you need to get information during the compilation process, you either need finer grained events, or another mechanism. This is a fun one to play with, but it is certainly doable. Cheers, Doru On Fri, May 15, 2015 at 7:30 AM, Tudor Girba <[email protected]> wrote: > 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" > -- www.tudorgirba.com "Every thing has its own flow"
