[Pharo-dev] Roassal Bug related to Athens?

Usman Bhatti usman.bhatti at gmail.com
Tue Dec 3 17:05:16 EST 2013


On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
>
>
> On 3 December 2013 15:21, Usman Bhatti <usman.bhatti at gmail.com> wrote:
>
>>
>> On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On 3 December 2013 14:18, Usman Bhatti <usman.bhatti at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131203/bb03c1ce/attachment-0002.html>


More information about the Pharo-dev mailing list