[Pharo-project] Transcript rant

Toon Verwaest toon.verwaest at gmail.com
Mon Apr 4 15:45:46 CEST 2011

+1 for both of Igor's mails!

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