> >>> +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. > It's that exactly what Igor was fighting for?
ah ok this was totally unclear. Stef >> 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. >>>>>> >>>>>> >>>> >>> >> > >
