On 4 April 2011 14:46, Fernando Olivero<[email protected]> 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<[email protected]> 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.
