[Pharo-project] Transcript rant

Toon Verwaest toon.verwaest at gmail.com
Mon Apr 4 15:53:27 CEST 2011


On 04/04/2011 03:50 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?
> 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