[Pharo-project] Transcript rant

Igor Stasenko siguctua at gmail.com
Mon Apr 4 15:11:06 CEST 2011


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



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Pharo-project mailing list