> +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. Stef > On 04/04/2011 03:11 PM, Igor Stasenko wrote: >> 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. >>>> >>>> >>> >> >> > >
