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. >> >> > > -- Best regards, Igor Stasenko AKA sig.
