[Pharo-project] Transcript rant
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.
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. 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?). 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. Fernando On Mon, Apr 4, 2011 at 2:28 PM, Igor Stasenko <siguctua@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.
On 4 April 2011 14:46, Fernando Olivero <fernando.olivero@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@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.
-- Best regards, Igor Stasenko AKA sig.
+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@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@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.
+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<fernando.olivero@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@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.
On 04/04/2011 03:50 PM, Stéphane Ducasse wrote:
+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? Stef
On 04/04/2011 03:11 PM, Igor Stasenko wrote:
On 4 April 2011 14:46, Fernando Olivero<fernando.olivero@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@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.
+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<fernando.olivero@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@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.
On 04/04/2011 03:55 PM, Stéphane Ducasse wrote:
+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. I don't know the implementation, nor the old nor the new. I just read his email and thought it made a lot of sense.
For example where he lost you, he's just saying that it shouldn't matter if the transcript is something that is showing something in a window in the image, or if it's streaming the data to some external client somewhere. The API should just be the writestream API where it's used, independent of how it's being viewed by the second user who is reading the output printed on the transcript. It sounds like at the moment it's mixed and the user can also start reading from the transcript... that seems wrong since the data might have been sent over the wire; thus being gone and not available anymore in the transcript. Viewing the transcript is something totally different than writing to it. cheers, Toon
On Apr 4, 2011, at 3:59 PM, Toon Verwaest wrote:
On 04/04/2011 03:55 PM, Stéphane Ducasse wrote:
+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. I don't know the implementation, nor the old nor the new. I just read his email and thought it made a lot of sense.
For example where he lost you, he's just saying that it shouldn't matter if the transcript is something that is showing something in a window in the image, or if it's streaming the data to some external client somewhere. The API should just be the writestream API where it's used, independent of how it's being viewed by the second user who is reading the output printed on the transcript.
I agree on that :)
It sounds like at the moment it's mixed and the user can also start reading from the transcript... that seems wrong since the data might have been sent over the wire; thus being gone and not available anymore in the transcript. Viewing the transcript is something totally different than writing to it.
Thanks.
cheers, Toon
On 4 April 2011 16:07, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Apr 4, 2011, at 3:59 PM, Toon Verwaest wrote:
On 04/04/2011 03:55 PM, Stéphane Ducasse wrote:
+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. I don't know the implementation, nor the old nor the new. I just read his email and thought it made a lot of sense.
For example where he lost you, he's just saying that it shouldn't matter if the transcript is something that is showing something in a window in the image, or if it's streaming the data to some external client somewhere. The API should just be the writestream API where it's used, independent of how it's being viewed by the second user who is reading the output printed on the transcript.
I agree on that :)
It sounds like at the moment it's mixed and the user can also start reading from the transcript... that seems wrong since the data might have been sent over the wire; thus being gone and not available anymore in the transcript. Viewing the transcript is something totally different than writing to it.
Thanks.
Yes. Consider and API of well established unix logging facility such as syslog.
From application's point of view there is only one direction in communication: it writes to syslog, and syslog then directs content somewhere else (and where exactly is doesn't matters and not a concern of application). And its also thread safe, of course (but not at cost of having only single way to do things). And apparently there is no API to read what is just written (like #ensureCr, which implies reading the last character from stream to check if it is cr).
In this respect an old implementation was much nicer in a sense that it could be replaced by different stream which responds to same protocol.. But now, Transcript is a class, and its much harder to replace it and as to me it is too hardwired. Maybe this is good for Cuis, but as to me, i consider Transcript as a generic/default logging facility in smalltalk system. I was planning to redirect Transcript to write to stdout when in headless mode (and when VMs will provide stdio communication out of the box). But how i suppose to do it now? Hacking existing class? And then again, what if someone wants to redirect transcript to socket (and its easy to imagine where we may need that - suppose you working with remote image and want to see its transcript). So, hacking the same class again? P.S. i know that maybe a preferable way to do logging is through 'self log:' protocol etc.. but lets face reality: there are a tons of code in system which using Transcript. And i don't think that we will abandon it in nearest future. So, lets just keep it and make it more nicer, but lets separate concerns. -- Best regards, Igor Stasenko AKA sig.
Yes. Consider and API of well established unix logging facility such as syslog. From application's point of view there is only one direction in communication: it writes to syslog, and syslog then directs content somewhere else (and where exactly is doesn't matters and not a concern of application). And its also thread safe, of course (but not at cost of having only single way to do things). And apparently there is no API to read what is just written (like #ensureCr, which implies reading the last character from stream to check if it is cr).
In this respect an old implementation was much nicer in a sense that it could be replaced by different stream which responds to same protocol.. But now, Transcript is a class, and its much harder to replace it and as to me it is too hardwired. Maybe this is good for Cuis, but as to me, i consider Transcript as a generic/default logging facility in smalltalk system. I was planning to redirect Transcript to write to stdout when in headless mode (and when VMs will provide stdio communication out of the box).
Yes we are in sync on that.
But how i suppose to do it now? Hacking existing class? And then again, what if someone wants to redirect transcript to socket (and its easy to imagine where we may need that - suppose you working with remote image and want to see its transcript). So, hacking the same class again?
Ok so how do we make progress?
P.S. i know that maybe a preferable way to do logging is through 'self log:' protocol etc.. but lets face reality: there are a tons of code in system which using Transcript. And i don't think that we will abandon it in nearest future. So, lets just keep it and make it more nicer, but lets separate concerns.
Ok so how do we make progress? My favorite strategy: reimplement and replace. If this means I'll have to do it... I can, but not this month. It will of course mean that everybody who relies on the old code will break... so we might need a transitional compatibility class; although I think that these users should just rewrite their code. It doesn't make sense whatsoever.
I don't have too much knowledge about the whole architecture though; and I'd prefer to spend time on getting my classbuilder in a state that it can be incorporated safely. That would be progress. cheers, Toon
On Apr 4, 2011, at 8:22 PM, Toon Verwaest wrote:
Ok so how do we make progress? My favorite strategy: reimplement and replace. If this means I'll have to do it... I can, but not this month. It will of course mean that everybody who relies on the old code will break... so we might need a transitional compatibility class; although I think that these users should just rewrite their code. It doesn't make sense whatsoever.
we could simply revert the changes of CUIS.
I don't have too much knowledge about the whole architecture though; and I'd prefer to spend time on getting my classbuilder in a state that it can be incorporated safely. That would be progress.
yes I prefer knowing you working on that :)
cheers, Toon
On Mon, Apr 4, 2011 at 11:44 AM, Igor Stasenko <siguctua@gmail.com> wrote: (snip)
In this respect an old implementation was much nicer in a sense that it could be replaced by different stream which responds to same protocol.. But now, Transcript is a class, and its much harder to replace it and as to me it is too hardwired. Maybe this is good for Cuis, but as to me, i consider Transcript as a generic/default logging facility in smalltalk system. I was planning to redirect Transcript to write to stdout when in headless mode (and when VMs will provide stdio communication out of the box). But how i suppose to do it now? Hacking existing class? And then again, what if someone wants to redirect transcript to socket (and its easy to imagine where we may need that - suppose you working with remote image and want to see its transcript). So, hacking the same class again?
I'm probably missing the point but: why can't you do something like this:? transcript := Smalltalk at: #Transcript. Smalltalk at: #Transcript put: somethingElse. Smalltalk at: #Transcript put: transcript. Cheers, Richo
P.S. i know that maybe a preferable way to do logging is through 'self log:' protocol etc.. but lets face reality: there are a tons of code in system which using Transcript. And i don't think that we will abandon it in nearest future. So, lets just keep it and make it more nicer, but lets separate concerns.
-- Best regards, Igor Stasenko AKA sig.
Hi igor I would like to try to understand and be more in positive thinking mode.
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?
so does what fernando replied true? In that case it does not look as a problem
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?
What is the implication at the design and use level of Transcript been a stream?
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?
you lost me here.
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...
Really?
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.
We can revert it if this is important Now let us try to learn. Stef
Make it simple, but not simpler (c) Albert Einstein.
-- Best regards, Igor Stasenko AKA sig.
Guys I need an update status. Do we keep or not the changes in the system? I will come back to you until we reach a decision :) Stef
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still believe that composition is better then inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead. Fernando On Tue, Apr 5, 2011 at 8:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Guys
I need an update status. Do we keep or not the changes in the system?
I will come back to you until we reach a decision :)
Stef
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS).
I still believe that composition is better then inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
That's totally not my concern. As long as thing which sits there responds to writestream protocol , i don't care about rest.
Fernando
On Tue, Apr 5, 2011 at 8:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Guys
I need an update status. Do we keep or not the changes in the system?
I will come back to you until we reach a decision :)
Stef
-- Best regards, Igor Stasenko AKA sig.
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still believe that composition is better then inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
That's totally not my concern. As long as thing which sits there responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code? My 0.0199999.... -- Cesar Rabak
On 6 April 2011 20:24, <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> Â Â wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich  points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still  believe that composition  is better then  inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
 That's totally  not my concern. As  long as thing  which sits there  responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel. See the latest post on 3948: Transcript and ThreadedTranscript needs to be merged. Fernando On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2011 20:24, Â <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> Â Â wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich  points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still  believe that composition  is better then  inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
 That's totally  not my concern. As  long as thing  which sits there  responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
How can I get the old transcript? Stef On Apr 7, 2011, at 9:58 AM, Fernando Olivero wrote:
I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel.
See the latest post on 3948: Transcript and ThreadedTranscript needs to be merged.
Fernando
On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2011 20:24, <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still believe that composition is better then inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
That's totally not my concern. As long as thing which sits there responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
From the release notes of CUIS: "New Transcript Fast (Calls return quickly) Fast (Updates are immediate) Thread safe Can log to file in addition to Display Display output is optional (for headless images) Can work on a bare bones image (Doesn't need UI, dependency, events, processes) Optional morphic window for seamless integration in Morphic UI framework agnostic. Can be used to debug Morphic, even with the morphic window open, without crashing the image! No longer a text editor. Display is read only."
The idea of the current Transcript are, not to use a standart widget for decoupling from Morphic, in case of errors the transcript still remains functional. I propose adding a new transcript morph, that has the previous functionality ( cut and paste ), but keep the new transcript model ( as in the ISSUE 3948). Fernando On Sun, Apr 17, 2011 at 6:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
How can I get the old transcript?
Stef
On Apr 7, 2011, at 9:58 AM, Fernando Olivero wrote:
I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel.
See the latest post on 3948: Â Transcript and ThreadedTranscript needs to be merged.
Fernando
On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2011 20:24, Â <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> Â Â wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich  points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still  believe that composition  is better then  inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
 That's totally  not my concern. As  long as thing  which sits there  responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
I know all that :) I favor changes. Now theadSafeTranscript was thread safe. How can I get the old transcript because I need to get fast for debugging an ugly bug.
From the release notes of CUIS: "New Transcript Fast (Calls return quickly) Fast (Updates are immediate) Thread safe Can log to file in addition to Display Display output is optional (for headless images) Can work on a bare bones image (Doesn't need UI, dependency, events, processes) Optional morphic window for seamless integration in Morphic UI framework agnostic. Can be used to debug Morphic, even with the morphic window open, without crashing the image! No longer a text editor. Display is read only."
The idea of the current Transcript are, not to use a standart widget for decoupling from Morphic, in case of errors the transcript still remains functional.
I propose adding a new transcript morph, that has the previous functionality ( cut and paste ), but keep the new transcript model ( as in the ISSUE 3948).
Fernando
On Sun, Apr 17, 2011 at 6:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
How can I get the old transcript?
Stef
On Apr 7, 2011, at 9:58 AM, Fernando Olivero wrote:
I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel.
See the latest post on 3948: Transcript and ThreadedTranscript needs to be merged.
Fernando
On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2011 20:24, <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still believe that composition is better then inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
That's totally not my concern. As long as thing which sits there responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
Ok! In the latest Pharo1.3 you can evaluate: Transcript rename: 'TranscriptModel'. Smalltalk globals at: #Transcript put: TranscriptStream new. If you load the issue 3948, then you dont need the first line. Fernando On Tue, Apr 19, 2011 at 9:14 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I know all that :) I favor changes. Now theadSafeTranscript was thread safe. How can I get the old transcript because I need to get fast for debugging an ugly bug.
From the release notes of CUIS: "New Transcript  Fast (Calls return quickly)  Fast (Updates are immediate)  Thread safe  Can log to file in addition to Display  Display output is optional (for headless images)  Can work on a bare bones image (Doesn't need UI, dependency, events, processes)  Optional morphic window for seamless integration in Morphic  UI framework agnostic. Can be used to debug Morphic, even with the morphic window open, without crashing the image!  No longer a text editor. Display is read only."
The idea of the current Transcript are, not to use a standart widget for decoupling from Morphic, in case of errors the transcript still remains functional.
I propose adding a new transcript morph, that has the previous functionality ( cut and paste ), but keep the new transcript model ( as in the ISSUE 3948).
Fernando
On Sun, Apr 17, 2011 at 6:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
How can I get the old transcript?
Stef
On Apr 7, 2011, at 9:58 AM, Fernando Olivero wrote:
I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel.
See the latest post on 3948: Â Transcript and ThreadedTranscript needs to be merged.
Fernando
On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2011 20:24, Â <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> Â Â wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich  points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still  believe that composition  is better then  inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
 That's totally  not my concern. As  long as thing  which sits there  responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
thanks fernando Stef On Apr 20, 2011, at 12:35 PM, Fernando Olivero wrote:
Ok! In the latest Pharo1.3 you can evaluate:
Transcript rename: 'TranscriptModel'. Smalltalk globals at: #Transcript put: TranscriptStream new.
If you load the issue 3948, then you dont need the first line.
Fernando
On Tue, Apr 19, 2011 at 9:14 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I know all that :) I favor changes. Now theadSafeTranscript was thread safe. How can I get the old transcript because I need to get fast for debugging an ugly bug.
From the release notes of CUIS: "New Transcript Fast (Calls return quickly) Fast (Updates are immediate) Thread safe Can log to file in addition to Display Display output is optional (for headless images) Can work on a bare bones image (Doesn't need UI, dependency, events, processes) Optional morphic window for seamless integration in Morphic UI framework agnostic. Can be used to debug Morphic, even with the morphic window open, without crashing the image! No longer a text editor. Display is read only."
The idea of the current Transcript are, not to use a standart widget for decoupling from Morphic, in case of errors the transcript still remains functional.
I propose adding a new transcript morph, that has the previous functionality ( cut and paste ), but keep the new transcript model ( as in the ISSUE 3948).
Fernando
On Sun, Apr 17, 2011 at 6:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
How can I get the old transcript?
Stef
On Apr 7, 2011, at 9:58 AM, Fernando Olivero wrote:
I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel.
See the latest post on 3948: Transcript and ThreadedTranscript needs to be merged.
Fernando
On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2011 20:24, <csrabak@bol.com.br> wrote:
Em 06/04/2011 09:07, Igor Stasenko <siguctua@gmail.com> escreveu:
On 6 April 2011 13:54, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi Stef, i will as an initial step take Igor's suggestion and make Transcript a global wich points to an instance of TranscriptModel ( the new name i propose for the current class taken from CUIS). I still believe that composition is better then inheritance for handling different behaviors of the Transcript, so i argue against making it a subclass of WriteStream and making it polymorphic with a write stream instead.
That's totally not my concern. As long as thing which sits there responds to writestream protocol , i don't care about rest.
Would it make sense then to lift the methods from {write}stream and put then in a Trait so the composition is made through reuse of code?
My 0.0199999....
hehe.. yes, but if to follow this road every time you need to do small improvement, then at some day you will discover that you rewriting whole system from scratch :)
-- Cesar Rabak
-- Best regards, Igor Stasenko AKA sig.
participants (6)
-
csrabak＠bol.com.br -
Fernando Olivero -
Igor Stasenko -
Ricardo Moran -
Stéphane Ducasse -
Toon Verwaest