Roassal Bug related to Athens?
Hello Igor, Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019 I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error. Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice? regards, Usman
On 2 December 2013 17:14, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
right.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago).
http://lmgtfy.com/?q=nativeboost+session+aware&l=1 regards,
Usman
-- Best regards, Igor Stasenko.
http://code.google.com/p/nativeboost/wiki/SessionManagement On 2 December 2013 22:02, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 December 2013 17:14, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
right.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago).
http://lmgtfy.com/?q=nativeboost+session+aware&l=1
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Mon, Dec 2, 2013 at 10:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:
This one's much more helpful.
On 2 December 2013 22:02, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 December 2013 17:14, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
right.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago).
http://lmgtfy.com/?q=nativeboost+session+aware&l=1
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Igor I see that you are learning the pattern: Write a simple doc [point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it point people to it ] until: [They got it] It is a massive amount of energy saving :) Stef On Dec 2, 2013, at 10:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:
http://code.google.com/p/nativeboost/wiki/SessionManagement
On 2 December 2013 22:02, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 December 2013 17:14, Usman Bhatti <usman.bhatti@gmail.com> wrote: Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
right.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago).
http://lmgtfy.com/?q=nativeboost+session+aware&l=1
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
and how exactly you expect that people would know what a session is ? or why that would be an issue with nativeboost or Athens ? I did not even know that there was a tutorial included about it in the Athens tutorial which is package that existing in the smalltalkhub repo of Athens in smalltalkhub for some strange reason the tutorial is not included with the standard distribution of Pharo 3 even though Athens suppose to play a huge role for Pharo in the future replacing all drawings. I have even purchased both Pharo books and they don't mention this. You cant blame him for not knowing or not googling about it. You cant google what you are not aware of. And you cant be aware if you dont have some sort of documentation in front of you. And no a maiing is not documentation. The least you could do is at smalltalkhub description tell to people to go fetch the Athens-Tutorial package and learn from it. At least that would save you a substantial amount of replies in the near future. From the tutorial alone he would have learned about the session issue and he would not have to ask and that would save him time and you. I love your work and appreciate your effort but whether we like it or not, these things are very important. On Mon, Dec 2, 2013 at 11:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 December 2013 17:14, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
right.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago).
http://lmgtfy.com/?q=nativeboost+session+aware&l=1
regards,
Usman
-- Best regards, Igor Stasenko.
Igor, I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well. So, to reproduce. AthensFlakeDemo new openInWorld save image open image I tested in Moose 5.0. 1. Should I open a bug entry in Pharo? 2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then. Usman On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree. Because then, files can also open/close and delete themselves automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework. But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it. Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
You are correct but so is Igor. Managing external resources has to do with VM and Nativeboost itself and not with Athens. This could happen with any other library. Session aware code is actually very easy to do and its explained Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines of code. In step2 method there is a relevant comment "IMPORTANT NOTE: the surface which we will create at this step will be used in later steps. This means that if you resize the window (changing the view size), you may need to recreate surface. Also, since surface uses external resources, quitting an image and restarting it, will also require to create a new surface, because the one from previous session will be no longer accessible. " but there is no mention to check the checkSession method for an example how sessions can be handled. I think this deserves a separate step by itself with a nice example. Igor you want me to give me commit rights to Athens repo to add that myself ? On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios@gmail.com> wrote:
You are correct but so is Igor. Managing external resources has to do with VM and Nativeboost itself and not with Athens. This could happen with any other library.
Session aware code is actually very easy to do and its explained Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines of code.
In step2 method there is a relevant comment
"IMPORTANT NOTE: the surface which we will create at this step will be used in later steps. This means that if you resize the window (changing the view size), you may need to recreate surface. Also, since surface uses external resources, quitting an image and restarting it, will also require to create a new surface, because the one from previous session will be no longer accessible. "
Ok. Tx. That's very useful info. I'll have a look.
but there is no mention to check the checkSession method for an example how sessions can be handled. I think this deserves a separate step by itself with a nice example. Igor you want me to give me commit rights to Athens repo to add that myself ?
And if you add the example to Athens, please let me know.
On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
you dont have to wait for my example as i said checkSession is already the example checkSession session == Smalltalk session ifFalse: [ "just reset the surface" surface := nil. session := Smalltalk session. ] as you can see here essentially we compare session if they differ then we know we need to reinitialize all our external resources in this example surface . Not that it assigns surfaces as nil but you will need to fully reinitialize the surface cause otherwise you will have a non existent surface still. In this class a nill surface is reinitialized by another method. Also I like to note here that Roassal Easel appear also not to check sessions and exhibits the known problem if image is stored with Easel open. Its something Roassal people would need to look at. On Tue, Dec 3, 2013 at 4:51 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios@gmail.com> wrote:
You are correct but so is Igor. Managing external resources has to do with VM and Nativeboost itself and not with Athens. This could happen with any other library.
Session aware code is actually very easy to do and its explained Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines of code.
In step2 method there is a relevant comment
"IMPORTANT NOTE: the surface which we will create at this step will be used in later steps. This means that if you resize the window (changing the view size), you may need to recreate surface. Also, since surface uses external resources, quitting an image and restarting it, will also require to create a new surface, because the one from previous session will be no longer accessible. "
Ok. Tx. That's very useful info. I'll have a look.
but there is no mention to check the checkSession method for an example how sessions can be handled. I think this deserves a separate step by itself with a nice example. Igor you want me to give me commit rights to Athens repo to add that myself ?
And if you add the example to Athens, please let me know.
On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
you dont have to wait for my example as i said checkSession is already the example
checkSession session == Smalltalk session ifFalse: [ "just reset the surface" surface := nil. session := Smalltalk session. ]
as you can see here essentially we compare session if they differ then we know we need to reinitialize all our external resources in this example surface . Not that it assigns surfaces as nil but you will need to fully reinitialize the surface cause otherwise you will have a non existent surface still. In this class a nill surface is reinitialized by another method.
Also I like to note here that Roassal Easel appear also not to check sessions and exhibits the known problem if image is stored with Easel open. Its something Roassal people would need to look at.
Yes I do not understand why this is not already in Roassal. Stef
On 3 December 2013 15:58, kilon alios <kilon.alios@gmail.com> wrote:
you dont have to wait for my example as i said checkSession is already the example
checkSession session == Smalltalk session ifFalse: [ "just reset the surface" surface := nil. session := Smalltalk session. ]
as you can see here essentially we compare session if they differ then we know we need to reinitialize all our external resources in this example surface . Not that it assigns surfaces as nil but you will need to fully reinitialize the surface cause otherwise you will have a non existent surface still. In this class a nill surface is reinitialized by another method.
Right. Another reason why Athens has nothing to do with it: if i don't want my surfaces to live longer than single session, the way to handle that will be completely different than in given example.
Also I like to note here that Roassal Easel appear also not to check sessions and exhibits the known problem if image is stored with Easel open. Its something Roassal people would need to look at.
On Tue, Dec 3, 2013 at 4:51 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios@gmail.com>wrote:
You are correct but so is Igor. Managing external resources has to do with VM and Nativeboost itself and not with Athens. This could happen with any other library.
Session aware code is actually very easy to do and its explained Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines of code.
In step2 method there is a relevant comment
"IMPORTANT NOTE: the surface which we will create at this step will be used in later steps. This means that if you resize the window (changing the view size), you may need to recreate surface. Also, since surface uses external resources, quitting an image and restarting it, will also require to create a new surface, because the one from previous session will be no longer accessible. "
Ok. Tx. That's very useful info. I'll have a look.
but there is no mention to check the checkSession method for an example how sessions can be handled. I think this deserves a separate step by itself with a nice example. Igor you want me to give me commit rights to Athens repo to add that myself ?
And if you add the example to Athens, please let me know.
On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I was able to resolve the problem in Roassal using session management. Tx Kilon and Igor for your help. Usman On Tue, Dec 3, 2013 at 3:58 PM, kilon alios <kilon.alios@gmail.com> wrote:
you dont have to wait for my example as i said checkSession is already the example
checkSession session == Smalltalk session ifFalse: [ "just reset the surface" surface := nil. session := Smalltalk session. ]
as you can see here essentially we compare session if they differ then we know we need to reinitialize all our external resources in this example surface . Not that it assigns surfaces as nil but you will need to fully reinitialize the surface cause otherwise you will have a non existent surface still. In this class a nill surface is reinitialized by another method.
Also I like to note here that Roassal Easel appear also not to check sessions and exhibits the known problem if image is stored with Easel open. Its something Roassal people would need to look at.
On Tue, Dec 3, 2013 at 4:51 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios@gmail.com>wrote:
You are correct but so is Igor. Managing external resources has to do with VM and Nativeboost itself and not with Athens. This could happen with any other library.
Session aware code is actually very easy to do and its explained Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines of code.
In step2 method there is a relevant comment
"IMPORTANT NOTE: the surface which we will create at this step will be used in later steps. This means that if you resize the window (changing the view size), you may need to recreate surface. Also, since surface uses external resources, quitting an image and restarting it, will also require to create a new surface, because the one from previous session will be no longer accessible. "
Ok. Tx. That's very useful info. I'll have a look.
but there is no mention to check the checkSession method for an example how sessions can be handled. I think this deserves a separate step by itself with a nice example. Igor you want me to give me commit rights to Athens repo to add that myself ?
And if you add the example to Athens, please let me know.
On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
On 3 December 2013 15:21, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
No need. There is one example: look at AthensSceneView
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
Surface is like file, you create it, delete it.. write to it..
the management of surfaces is absolutely out of scope of framework. More than that, surfaces is not something which you operate with usually. Because usually its just a canvas. But I would understand the absence of such a mechanism in the framework but
then a tutorial should explain to novices/first-timers how to do it.
this sort of things is tiniest (but of course necessary) parts of whole application, and usually will belong to some service layers built around/on top of athens. in future, sure thing you won't need to care about it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 15:21, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
No need. There is one example: look at AthensSceneView
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
Surface is like file, you create it, delete it.. write to it..
the management of surfaces is absolutely out of scope of framework. More than that, surfaces is not something which you operate with usually. Because usually its just a canvas.
Still, I will maintain that a minimalistic session logic should be built by default in Athens. Because otherwise each application has to maintain a session instance variable and a logic to test that session hasn't changed in between to keep a surface alive, which is lowest common denominator for all the applications using Athens. regards, Usman
But I would understand the absence of such a mechanism in the framework
but then a tutorial should explain to novices/first-timers how to do it.
this sort of things is tiniest (but of course necessary) parts of whole application, and usually will belong to some service layers built around/on top of athens. in future, sure thing you won't need to care about it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 3 December 2013 23:05, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 15:21, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
No need. There is one example: look at AthensSceneView
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
Surface is like file, you create it, delete it.. write to it..
the management of surfaces is absolutely out of scope of framework. More than that, surfaces is not something which you operate with usually. Because usually its just a canvas.
Still, I will maintain that a minimalistic session logic should be built by default in Athens. Because otherwise each application has to maintain a session instance variable and a logic to test that session hasn't changed in between to keep a surface alive, which is lowest common denominator for all the applications using Athens.
Usman, i have impression that you didn't looked at code at all.
AthensSurface subclass: #AthensCairoSurface uses: TCairoLibrary instanceVariableNames: 'handle context builder id ftFontRenderer session' classVariableNames: '' poolDictionaries: 'AthensCairoDefs' category: 'Athens-Cairo' what you think 'session' ivar and checkSession method does there? You can make subclass if you want and redefine default behavior. But my main problem that you still don't see that the code in example(s) is NOT the lowest common denominator for all applications using Athens. Lowest common denominator is Athens API. Athens API defines and describes roles (surface, canvas, paints etc) and their protocols, but NOT how to create/initialize and manage such objects.
regards,
Usman
But I would understand the absence of such a mechanism in the framework
but then a tutorial should explain to novices/first-timers how to do it.
this sort of things is tiniest (but of course necessary) parts of whole application, and usually will belong to some service layers built around/on top of athens. in future, sure thing you won't need to care about it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
So, in a meeting, Igor convinced me that surface cannot be handled at the level of framework. The reason is that the surfaces in athens created by the client applications have some application-level semantics such as extent, that cannot be known by the framework. So, application has to integrate session logic so that surface is initialized whenever image is restarted. Hence, checkSession default implementation in Athens throws an exception. For new comers like me, for creating surfaces and maintaining surfaces, this is useful to understand the session checking code : AthensFlakeDemo new openInWorld. I hope this helps others. Usman On Tue, Dec 3, 2013 at 11:21 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 23:05, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 3 December 2013 15:21, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
No need. There is one example: look at AthensSceneView
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree.
Because then, files can also open/close and delete themselves
automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
Surface is like file, you create it, delete it.. write to it..
the management of surfaces is absolutely out of scope of framework. More than that, surfaces is not something which you operate with usually. Because usually its just a canvas.
Still, I will maintain that a minimalistic session logic should be built by default in Athens. Because otherwise each application has to maintain a session instance variable and a logic to test that session hasn't changed in between to keep a surface alive, which is lowest common denominator for all the applications using Athens.
Usman, i have impression that you didn't looked at code at all.
AthensSurface subclass: #AthensCairoSurface uses: TCairoLibrary instanceVariableNames: 'handle context builder id ftFontRenderer session' classVariableNames: '' poolDictionaries: 'AthensCairoDefs' category: 'Athens-Cairo'
what you think 'session' ivar and checkSession method does there? You can make subclass if you want and redefine default behavior.
But my main problem that you still don't see that the code in example(s) is NOT the lowest common denominator for all applications using Athens. Lowest common denominator is Athens API. Athens API defines and describes roles (surface, canvas, paints etc) and their protocols, but NOT how to create/initialize and manage such objects.
regards,
Usman
But I would understand the absence of such a mechanism in the framework
but then a tutorial should explain to novices/first-timers how to do it.
this sort of things is tiniest (but of course necessary) parts of whole application, and usually will belong to some service layers built around/on top of athens. in future, sure thing you won't need to care about it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com>wrote:
Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
And what is important to see is that when Pharo will use Athens fully, the system will manage the surface since it acts as the current display. and AthensSceneView is a good to see a morph embedding its own surface and that should serve as a mini full world in which athens widgets can be drawn. Stef
So, in a meeting, Igor convinced me that surface cannot be handled at the level of framework. The reason is that the surfaces in athens created by the client applications have some application-level semantics such as extent, that cannot be known by the framework. So, application has to integrate session logic so that surface is initialized whenever image is restarted.
Hence, checkSession default implementation in Athens throws an exception.
For new comers like me, for creating surfaces and maintaining surfaces, this is useful to understand the session checking code : AthensFlakeDemo new openInWorld.
I hope this helps others.
Usman
On Tue, Dec 3, 2013 at 11:21 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 23:05, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 15:21, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 December 2013 14:18, Usman Bhatti <usman.bhatti@gmail.com> wrote: Igor,
I had a look at Athens demo to understand how to manage sessions and surfaces because Roassal uses AthensSurface and there is a defensive mechanism in place in Roassal to initialize the surface in case it is not done. In the meantime, I have discovered that the red rectangle bug is present in Athens demos as well.
So, to reproduce. AthensFlakeDemo new openInWorld save image open image
I tested in Moose 5.0.
1. Should I open a bug entry in Pharo?
only if you intend to fix it. because this demo was not intended to be 'fully featured, end-user compatible and fool-proof demo'. it just a demo to show animation and discard it, but if you insist this is a bug, feel free to fix it.
Unfortunately, I wont have time for this. For me it would have been good, had Athens provided an example of session management as a good client so that example-oriented people like me could understand easily. Because, otherwise, I'll have to look at the code of NativeBoost and that adds to the level of complexity because I would do things with trial and error.
No need. There is one example: look at AthensSceneView
2. With my superficial knowledge of Athens, my guess is that the session management can be done in Athens so that Roassal (and other tools built on top of Athens) do not need to do it. May be it is the case already but the demos are not using it then.
I disagree. Because then, files can also open/close and delete themselves automatically, so you will be left only to do reading and writing... Resource management is an application-level responsibility, not framework level. I cannot predict in Athens, how often one wants to create/destroy or (re)use surfaces, and therefore i cannot create and dispose them when i see fit within framework. Correct me if i wrong.
I think this doesn't compare to file handling because there are many types of operations possible on files and that are application-specific. Here resource management is actually exception-handling: I should not give to my client a surface that does not exist any more. Now, of course, if there is some application-level intelligence is involved, we cannot put that in the framework.
Surface is like file, you create it, delete it.. write to it.. the management of surfaces is absolutely out of scope of framework. More than that, surfaces is not something which you operate with usually. Because usually its just a canvas.
Still, I will maintain that a minimalistic session logic should be built by default in Athens. Because otherwise each application has to maintain a session instance variable and a logic to test that session hasn't changed in between to keep a surface alive, which is lowest common denominator for all the applications using Athens.
Usman, i have impression that you didn't looked at code at all.
AthensSurface subclass: #AthensCairoSurface uses: TCairoLibrary instanceVariableNames: 'handle context builder id ftFontRenderer session' classVariableNames: '' poolDictionaries: 'AthensCairoDefs' category: 'Athens-Cairo'
what you think 'session' ivar and checkSession method does there? You can make subclass if you want and redefine default behavior.
But my main problem that you still don't see that the code in example(s) is NOT the lowest common denominator for all applications using Athens. Lowest common denominator is Athens API. Athens API defines and describes roles (surface, canvas, paints etc) and their protocols, but NOT how to create/initialize and manage such objects.
regards,
Usman
But I would understand the absence of such a mechanism in the framework but then a tutorial should explain to novices/first-timers how to do it.
this sort of things is tiniest (but of course necessary) parts of whole application, and usually will belong to some service layers built around/on top of athens. in future, sure thing you won't need to care about it.
Usman
Usman
On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote: Hello Igor,
Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019
I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error.
Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice?
regards,
Usman
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (4)
-
Igor Stasenko -
kilon alios -
Stéphane Ducasse -
Usman Bhatti