[Pharo-project] Transcript rant

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Apr 4 15:50:31 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.

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