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 <btc@openinworld.com> 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 <stepharo@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������