[Pharo-project] Transcript rant

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Apr 4 15:55:23 CEST 2011

>>> +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.


>> Stef
>>> On 04/04/2011 03:11 PM, Igor Stasenko wrote:
>>>> On 4 April 2011 14:46, Fernando Olivero<fernando.olivero at usi.ch>   wrote:
>>>>> Transcript could be polymorphic with a Stream, not necessarily a
>>>>> subclass. Lets identify the methods that are missing and add them. For
>>>>> instance, existing methods are: Transcript class>>   nextPutAll:
>>>>> aString.
>>>> To my sense, its basic protocol should be write stream. And additional methods,
>>>> like endEntry could be there for compatibility.
>>>>> Transcript is the model. TranscriptMorph is the view. Currently the
>>>>> morph just displays a Form showing the model's contents. Wouldn't take
>>>>> much to alter to present a TextMorph ( read-only right?).
>>>> Why read only? Who cares? All that view needs is to append a new entry
>>>> to text morph once new content are coming in.
>>>> If user wants to edit it or clear it later, let him do it. What user
>>>> does is changing the text morph contents , but not transcript
>>>> contents,
>>>> because there is no such. An entry, once written to transcript, its gone.
>>>> It should not preserve it if there is nobody listens for it.
>>>> Why it should preserve all , what is written there, only to show on
>>>> read-only morphic view?
>>>> And how about selecting text? And how about clearing it?
>>>> Should i clear it manually every time a stream size gets over multiple
>>>> megabytes?
>>>> It is wrong. A view is just a text morph, which appends new entries if
>>>> new content comes in.
>>>> If users wants to edit this morph or clear it, its not a problem,
>>>> because user cannot edit stream contents.. there is no stream
>>>> contents,
>>>> because transcript stream is write-only stream.
>>>> Which means if you don't capture what is written into it, then its
>>>> gone and lost.
>>>> A proper view for write only stream is just capture newly incoming
>>>> content, but not read from some stream,
>>>> because that implies that stream are readable and there are something
>>>> which keeps its contents.. but its not.
>>>>> Transcript behavior is in the class side because somehow its mimicking
>>>>> a singleton, Transcript is still supposed to be unique in the image.
>>>>> And thread safe, and enabling logging to file also.
>>>> What makes things thread safe? Thread safety means that nobody could
>>>> access a state of object,
>>>> when its in the middle of change operation.
>>>> But since transcript is a write-only stream, there is no access to its
>>>> state possible (you cannot read stuff which are written to it).
>>>> You could just place a notifier which forwards what is written to it
>>>> to some view..
>>>> And there is totally no need to maintain some internal state for
>>>> transcript to access it later, and therefore its thread safe by
>>>> default.
>>>>> Fernando
>>>>> On Mon, Apr 4, 2011 at 2:28 PM, Igor Stasenko<siguctua at gmail.com>   wrote:
>>>>>> It is broken, badly broken..
>>>>>> of course its a piece of cake to add #ensureCr method , so VMMaker
>>>>>> will work properly..
>>>>>> but the problem is that Transcript from Cuis is even worse than we had before.
>>>>>> First thing, is that Transcript is no longer a global variable, but
>>>>>> instead a singleton class (Transcript).
>>>>>> So, now, what i suppose to do if i want to redirect all
>>>>>> Transcript show: ...
>>>>>> to file instead of in-image stream?
>>>>>> Second. I told it before and i will repeat it again.
>>>>>> Transcript ===== WriteStream
>>>>>> yes, it is stream.
>>>>>> And Transcript as a tool  - a window which you see on desktop is a
>>>>>> view of that stream. Do you follow?  Transcript is model, and
>>>>>> transcript window is view. Simple enough?
>>>>>> Then why its not like that?
>>>>>> So, we should have a model,  which is a stream,
>>>>>> and as many as we like views, which simply listening of updates on
>>>>>> that stream and updating their view correspondingly..
>>>>>> This means that to do it right, we should do something like following:
>>>>>> - Transcript is a stream, but which also notifies the view(s) about
>>>>>> new stuff coming in, so views can react and update themselves
>>>>>> - Transcript is write only stream, and any attempts to seek or read
>>>>>> from it should be prohibited. Sorry guys.. if i'd like to do
>>>>>> transcript logging via socket,
>>>>>> where i suppose to take a content which i already sent via wire?
>>>>>> it would be really nice to have xtreams, which allow stream
>>>>>> composition.. so then transcript is a composed stream of a following
>>>>>> form:
>>>>>> notifier stream ->   output stream
>>>>>> notifier stream is direct any writes to output stream, but in addition
>>>>>> it notifies any listeners about new content are written to it. This is
>>>>>> easy to implement using xtreams..
>>>>>> but not so easy with old streams (but its doable).
>>>>>> An output stream could be anything, which application/image wants to be.
>>>>>> For obvious reasons, i'd like to redirect all transcript output in
>>>>>> headless mode to stdout. It was doable with old implementation.. but
>>>>>> with a new one its impossible, because then i will need to replace
>>>>>> class with something else,
>>>>>> and then restore it back when i have to switch back to normal operation...
>>>>>> Views.. Views are receiving notifications and update their own
>>>>>> contents (usually text morphs). There could be as many as one wants
>>>>>> views on transcript stream. Not only one.
>>>>>> I really don't like that in new transcript i can't even select a text
>>>>>> or clear window... from my POV this is what called regression.
>>>>>> Make it simple, but not simpler (c) Albert Einstein.
>>>>>> --
>>>>>> Best regards,
>>>>>> Igor Stasenko AKA sig.

More information about the Pharo-project mailing list