On 4 April 2011 16:07, Stéphane Ducasse <[email protected]> wrote: > > On Apr 4, 2011, at 3:59 PM, Toon Verwaest wrote: > >> On 04/04/2011 03:55 PM, Stéphane Ducasse wrote: >>>>>> +1 for both of Igor's mails! >>>>> Why? this is really important to have threadsafe transcript and it is >>>>> good to have a look at >>>>> what juan did. >>>>> >>>>> We should be able to use a transcript even without morph. >>>> It's that exactly what Igor was fighting for? >>> ah ok this was totally unclear. >> I don't know the implementation, nor the old nor the new. I just read his >> email and thought it made a lot of sense. >> >> For example where he lost you, he's just saying that it shouldn't matter if >> the transcript is something that is showing something in a window in the >> image, or if it's streaming the data to some external client somewhere. The >> API should just be the writestream API where it's used, independent of how >> it's being viewed by the second user who is reading the output printed on >> the transcript. > > I agree on that :) > >> It sounds like at the moment it's mixed and the user can also start reading >> from the transcript... that seems wrong since the data might have been sent >> over the wire; thus being gone and not available anymore in the transcript. >> Viewing the transcript is something totally different than writing to it. > > Thanks. >
Yes. Consider and API of well established unix logging facility such as syslog. >From application's point of view there is only one direction in communication: it writes to syslog, and syslog then directs content somewhere else (and where exactly is doesn't matters and not a concern of application). And its also thread safe, of course (but not at cost of having only single way to do things). And apparently there is no API to read what is just written (like #ensureCr, which implies reading the last character from stream to check if it is cr). In this respect an old implementation was much nicer in a sense that it could be replaced by different stream which responds to same protocol.. But now, Transcript is a class, and its much harder to replace it and as to me it is too hardwired. Maybe this is good for Cuis, but as to me, i consider Transcript as a generic/default logging facility in smalltalk system. I was planning to redirect Transcript to write to stdout when in headless mode (and when VMs will provide stdio communication out of the box). But how i suppose to do it now? Hacking existing class? And then again, what if someone wants to redirect transcript to socket (and its easy to imagine where we may need that - suppose you working with remote image and want to see its transcript). So, hacking the same class again? P.S. i know that maybe a preferable way to do logging is through 'self log:' protocol etc.. but lets face reality: there are a tons of code in system which using Transcript. And i don't think that we will abandon it in nearest future. So, lets just keep it and make it more nicer, but lets separate concerns. -- Best regards, Igor Stasenko AKA sig.
