[Pharo-dev] Questions about Athens

Igor Stasenko siguctua at gmail.com
Wed Nov 13 07:18:49 EST 2013


I doubt it is related to Athens. I think it is initialization problem.
If morph's extent depends on external factors, you should properly
initialize them
before computing it.
It could be that you calling #checkSession before.. which leads to DNU,
because no extent can be computed at given point yet.

On 12 November 2013 12:59, kilon alios <kilon.alios at gmail.com> wrote:

> Igor just for the record, I still have not figure out why I had this
> problem in the first place. I was using self extent and that was giving me
> a NB error as I posted in the first stack trace. I changed it to self
> defaultExtent that returns a point with the default size of the area of the
> Morph and voila it worked. I checked the Hierachy and Morph which is the
> super class of Hyperion has an extent method so this should work. So I
> think this may be an Athens bug after all.
>
> So i changed the method from
>
> checkSession
> session == Smalltalk session ifFalse: [surface := AthensCairoSurface
> extent: self extent . session := Smalltalk session  ]
>
> to
>
> checkSession
> session == Smalltalk session ifFalse: [surface := AthensCairoSurface
> extent: self defaultExtent . session := Smalltalk session  ]
>
> and now it works properly for some strange reason. At first I thought it
> was because there was no self extent method but now I see thats not the
> case.
>
>
> On Tue, Nov 12, 2013 at 1:20 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>>
>>
>>
>> On 11 November 2013 21:47, kilon alios <kilon.alios at gmail.com> wrote:
>>
>>> Ignore my last messages. Apparently I had an error with my code I just
>>> did not understand the error report. Everything works fone now.
>>>
>>
>> :)
>>
>>
>>> Στις 11 Νοε 2013 4:46 μ.μ., ο χρήστης "kilon alios" <
>>> kilon.alios at gmail.com> έγραψε:
>>>
>>>  sorry previous stack was for slightly diffirent code this is the
>>>> correct one
>>>>
>>>> UndefinedObject(Object)>>doesNotUnderstand: #drawDuring:
>>>> Hyperion>>render
>>>> Hyperion>>drawOn:
>>>> FormCanvas(Canvas)>>draw:
>>>> FormCanvas(Canvas)>>drawMorph:
>>>> Hyperion(Morph)>>fullDrawOn: in Block: [ ...
>>>> FormCanvas>>roundCornersOf:in:during:
>>>> FormCanvas(Canvas)>>roundCornersOf:during:
>>>> Hyperion(Morph)>>fullDrawOn: in Block: [ ...
>>>> BlockClosure>>on:do:
>>>> Hyperion(Morph)>>fullDrawOn:
>>>> FormCanvas(Canvas)>>fullDraw:
>>>> FormCanvas(Canvas)>>fullDrawMorph:
>>>> SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :m | canvas
>>>> fullDrawMorph: m ]
>>>> Array(SequenceableCollection)>>reverseDo:
>>>> SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :canvas | submorphs
>>>> reverseDo: [ :m | canvas ful...etc...
>>>> FormCanvas>>clipBy:during:
>>>> SystemWindow(Morph)>>drawSubmorphsOn:
>>>> SystemWindow(Morph)>>fullDrawOn: in Block: [ ...
>>>> FormCanvas>>roundCornersOf:in:during:
>>>> FormCanvas(Canvas)>>roundCornersOf:during:
>>>> SystemWindow(Morph)>>fullDrawOn: in Block: [ ...
>>>> BlockClosure>>on:do:
>>>> SystemWindow(Morph)>>fullDrawOn:
>>>> FormCanvas(Canvas)>>fullDraw:
>>>> FormCanvas(Canvas)>>fullDrawMorph:
>>>> WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: drawWorld:
>>>> aWorld submorphs: submorphs invalidArea...etc...
>>>> Rectangle>>allAreasOutsideList:startingAt:do:
>>>> Rectangle>>allAreasOutsideList:do:
>>>> WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: [ :dirtyRect
>>>> | ...
>>>>
>>>>
>>>>
>>>> On Mon, Nov 11, 2013 at 4:43 PM, kilon alios <kilon.alios at gmail.com>wrote:
>>>>
>>>>> Igor I am trying your session code but it does not work for me. I
>>>>> still get the red box of doom. This is the method
>>>>>
>>>>> checkSession
>>>>>
>>>>> session == Smalltalk session ifFalse: [
>>>>>  surface := surface := AthensCairoSurface extent: self extent. .
>>>>>  session := Smalltalk session.
>>>>>  ]
>>>>>
>>>>> and This is my full stack
>>>>>
>>>>> NBFFICallout class>>signalError:
>>>>> NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode:
>>>>> NBFFICalloutAPI>>function:module:
>>>>> AthensCairoSurface class(Object)>>nbCall:
>>>>> AthensCairoSurface class>>primImage:width:height:
>>>>> NBFFICallout class(NBNativeCodeGen class)>>retrySend:
>>>>> AthensCairoSurface class>>extent:format:
>>>>> AthensCairoSurface class>>extent:
>>>>> Hyperion>>mouseDown:
>>>>> Hyperion(Morph)>>handleMouseDown:
>>>>> MouseButtonEvent>>sentTo:
>>>>> Hyperion(Morph)>>handleEvent:
>>>>> MorphicEventDispatcher>>dispatchMouseDown:with:
>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>> Hyperion(Morph)>>processEvent:using:
>>>>> MorphicEventDispatcher>>dispatchMouseDown:with:
>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>> SystemWindow(Morph)>>processEvent:using:
>>>>> SystemWindow(Morph)>>processEvent:
>>>>> SystemWindow>>mouseDown: in Block: [ ...
>>>>> BlockClosure>>ensure:
>>>>> SystemWindow>>mouseDown:
>>>>> SystemWindow(Morph)>>handleMouseDown:
>>>>> MouseButtonEvent>>sentTo:
>>>>> SystemWindow(Morph)>>handleEvent:
>>>>> MorphicEventDispatcher>>dispatchMouseDown:with:
>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>> SystemWindow(Morph)>>processEvent:using:
>>>>> MorphicEventDispatcher>>dispatchMouseDown:with:
>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 2, 2013 at 12:01 PM, kilon alios <kilon.alios at gmail.com>wrote:
>>>>>
>>>>>> and here is the strange MNU that I was talking about earlier
>>>>>>
>>>>>> here is the full stack
>>>>>>
>>>>>> Hyperion(Object)>>doesNotUnderstand: #passenger
>>>>>> PackageTreeModel>>acceptDroppingMorph:event:inMorph:
>>>>>> MorphTreeMorph>>acceptDroppingMorph:event:
>>>>>> MorphTreeMorph(Morph)>>handleDropMorph:
>>>>>> DropEvent>>sentTo:
>>>>>> MorphTreeMorph(Morph)>>handleEvent:
>>>>>> MorphicEventDispatcher>>dispatchDropEvent:with:
>>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>>> MorphTreeMorph(Morph)>>processEvent:using:
>>>>>> MorphicEventDispatcher>>dispatchDropEvent:with:
>>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>>> PanelMorph(Morph)>>processEvent:using:
>>>>>> MorphicEventDispatcher>>dispatchDropEvent:with:
>>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>>> NautilusWindow(Morph)>>processEvent:using:
>>>>>> MorphicEventDispatcher>>dispatchDropEvent:with:
>>>>>> MorphicEventDispatcher>>dispatchEvent:with:
>>>>>> WorldMorph(Morph)>>processEvent:using:
>>>>>> WorldMorph(Morph)>>processEvent:
>>>>>> HandMorph>>sendEvent:focus:clear:
>>>>>> HandMorph>>sendEvent:focus:
>>>>>> HandMorph>>dropMorph:event:
>>>>>> HandMorph>>dropMorphs: in Block: [ :m | ...
>>>>>> Array(SequenceableCollection)>>reverseDo:
>>>>>> HandMorph(Morph)>>submorphsReverseDo:
>>>>>> HandMorph>>dropMorphs:
>>>>>> HandMorph>>handleEvent:
>>>>>> HandMorph>>processEvents
>>>>>> WorldState>>doOneCycleNowFor: in Block: [ :h | ...
>>>>>> Array(SequenceableCollection)>>do:
>>>>>>
>>>>>>
>>>>>> This one happens when I bring up the halos and try to move the morph
>>>>>> around.Morphs gets deleted because of MNU. Note it does not happen with
>>>>>> just my Class (Hyperion) it happens with any morph using Athens.
>>>>>>
>>>>>> Hyperion in this case is a partial copy of the AthensDemoMorph. As
>>>>>> always I am using Pharo 3 (Latest update: #30534) .
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 1, 2013 at 7:14 PM, Igor Stasenko <siguctua at gmail.com>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1 November 2013 14:32, Stéphane Ducasse <
>>>>>>> stephane.ducasse at inria.fr> wrote:
>>>>>>>
>>>>>>>> Ok now the explanation :)
>>>>>>>> Spec changed recently in 30.
>>>>>>>>
>>>>>>>>
>>>>>>> then i need help on that.. what is needs to be changed.
>>>>>>> btw, i noticed that monticello configuration browser also having
>>>>>>> problems with spec.
>>>>>>>
>>>>>>>
>>>>>>>> Stef
>>>>>>>>
>>>>>>>>
>>>>>>>> Again I am following Igor instructions, loaded Athens-Tutorial from
>>>>>>>> smalltalkhub , opened a new workspace, AthensTutorial open. I am using a
>>>>>>>> pharo 3 that downloaded just yesterday. (Pharo3.0 Latest update: #30532)
>>>>>>>>
>>>>>>>> here is the full stack
>>>>>>>>
>>>>>>>> AthensViewMorph(Object)>>doesNotUnderstand: #layout:
>>>>>>>> SpecInterpreter>>actionToPerformWithSelector:arguments:
>>>>>>>> SpecInterpreter>>performNextSelectorAndIncrementIndex
>>>>>>>> SpecInterpreter>>interpretASpec:selector:
>>>>>>>> SpecInterpreter>>interpretASpec:model:selector:
>>>>>>>> SpecInterpreter class>>private_interpretASpec:model:selector:
>>>>>>>> SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [
>>>>>>>> :each | self class private_interpretASpec: each ...etc...
>>>>>>>> Array(SequenceableCollection)>>collect:
>>>>>>>> SpecInterpreter>>performNextSelectorAndIncrementIndex
>>>>>>>> SpecInterpreter>>interpretASpec:selector:
>>>>>>>> SpecInterpreter>>interpretASpec:model:selector:
>>>>>>>> SpecInterpreter class>>private_interpretASpec:model:selector:
>>>>>>>> SpecInterpreter class>>interpretASpec:model:selector: in Block: [
>>>>>>>> result := self private_interpretASpec: aPresente...etc...
>>>>>>>> BlockClosure>>ensure:
>>>>>>>> SpecInterpreter class>>interpretASpec:model:selector:
>>>>>>>> SpecInterpreter class>>interpretASpec:model:
>>>>>>>> AthensTutorial(ComposableModel)>>buildWithSpecLayout:
>>>>>>>> MorphicWindowAdapter>>addModelIn:withSpecLayout:
>>>>>>>> MorphicWindowAdapter(AbstractAdapter)>>update:with:
>>>>>>>> WindowModel(Object)>>changed:with: in Block: [ :aDependent |
>>>>>>>> aDependent update: anAspect with: ...etc...
>>>>>>>> DependentsArray>>do:
>>>>>>>> WindowModel(Object)>>changed:with:
>>>>>>>> WindowModel>>addModelIn:withSpecLayout:
>>>>>>>> WindowModel>>buildWithSpecLayout:
>>>>>>>> WindowModel>>openWithSpecLayout:
>>>>>>>> AthensTutorial(ComposableModel)>>openWithSpecLayout:
>>>>>>>> AthensTutorial(ComposableModel)>>openWithSpec:
>>>>>>>> AthensTutorial(ComposableModel)>>openWithSpec
>>>>>>>> AthensTutorial class>>open
>>>>>>>> UndefinedObject>>DoIt
>>>>>>>>
>>>>>>>> Is that enough ?
>>>>>>>>
>>>>>>>> I am also getting another error from Athens from time to time, I
>>>>>>>> will have to remember to capture it cause it appears randomly.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Nov 1, 2013 at 1:42 PM, Stéphane Ducasse <
>>>>>>>> stephane.ducasse at inria.fr> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Igor I got Athens-Tutorial but it gives me a MNU:
>>>>>>>>> AthensViewMorph>>layout:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> strange tell us more.
>>>>>>>>> You know
>>>>>>>>>  which image
>>>>>>>>> ….
>>>>>>>>>
>>>>>>>>> Stef
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Nov 1, 2013 at 10:23 AM, kilon alios <
>>>>>>>>> kilon.alios at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> ShivaVG looks definitely as a way to ease the pain of porting to
>>>>>>>>>> OpenGL.
>>>>>>>>>>
>>>>>>>>>> Some notes on the matter. The Cairo backend for OpenGL is opengl
>>>>>>>>>> but yet its not opengl.  What it does is render cairo as a opengl texture.
>>>>>>>>>> OpenGL true power is in the shaders so you dont get the kind of hardware
>>>>>>>>>> acceleration you would expect.
>>>>>>>>>>
>>>>>>>>>> Speewise as surprising this may sound  opengl is not the ideal
>>>>>>>>>> option, because opengl is mainly 3d orientated. The ideal solution from
>>>>>>>>>> what I have seen would be something like CUDA or OpenCL, that give direct
>>>>>>>>>> access to the GPU cores and allow you to do any kind of computation thus
>>>>>>>>>> liberation from the restrictions of APIs. For example Blender takes
>>>>>>>>>> advantage of both Opengl and CUDA , the CUDA renderer is phenomenal better
>>>>>>>>>> because of its flexibility.
>>>>>>>>>>
>>>>>>>>>> The problem however is that all that are very technical and it
>>>>>>>>>> takes quite some dedication to implement.
>>>>>>>>>>
>>>>>>>>>> A reason why I abandoned opengl as an idea is that I came to
>>>>>>>>>> realise that Cairo was already fast enough for my needs. But I still keep
>>>>>>>>>> that door open for the distant future, ShivaVG with OpenCL would be awesome
>>>>>>>>>> for really intensive GUIs and complex Graphics and definitely would love to
>>>>>>>>>> give it another try eventually.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 1, 2013 at 2:19 AM, Igor Stasenko <siguctua at gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1 November 2013 00:53, Alexandre Bergel <
>>>>>>>>>>> alexandre.bergel at me.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Not sure to fully understand the problem. In what ShivaVG would
>>>>>>>>>>>> solve a situation better than with Athens? If I understand well, a then
>>>>>>>>>>>> working with Cairo uses the hardware acceleration right?
>>>>>>>>>>>> What is it not enough for you need?
>>>>>>>>>>>>
>>>>>>>>>>>> First, OpenVG is more complete and i would say thoroughly
>>>>>>>>>>> designed API than Cairo.
>>>>>>>>>>> Second, i don't want to go  Athens -> Cairo -> OpenGL
>>>>>>>>>>> if i can do directly Athens->OpenGL.
>>>>>>>>>>> Putting extra dependency out of the loop is advantageous, OpenGL
>>>>>>>>>>> is widely supported industry standard, which today you can find even on
>>>>>>>>>>> portable devices, while you cannot say same about Cairo.
>>>>>>>>>>>  (not mentioning avoiding costs of having multiple layers to get
>>>>>>>>>>> to the hardware).
>>>>>>>>>>>
>>>>>>>>>>> ShivaVG implements OpenVG API using OpenGL, since OpenVG is
>>>>>>>>>>> vector graphics framework
>>>>>>>>>>> it can serve as a good source to look how to implement OpenGL
>>>>>>>>>>> backend for Athens.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Alexandre
>>>>>>>>>>>>
>>>>>>>>>>>> > Le 31-10-2013 à 19:16, Igor Stasenko <siguctua at gmail.com> a
>>>>>>>>>>>> écrit :
>>>>>>>>>>>> >
>>>>>>>>>>>> > I cannot say, of course, how it would be for you, but there
>>>>>>>>>>>> is ShivaVG[1] open-source
>>>>>>>>>>>> > opengl implementation of OpenVG, more or less
>>>>>>>>>>>> feature-complete,
>>>>>>>>>>>> > so all what is needed is to port this code from C to
>>>>>>>>>>>> smalltalk.
>>>>>>>>>>>> > Or if not for porting, but using as a source of insights how
>>>>>>>>>>>> to implement it.
>>>>>>>>>>>> > I think it is fairly doable.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Igor Stasenko.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Igor Stasenko.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>> --
>> 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/20131113/db816192/attachment-0002.html>


More information about the Pharo-dev mailing list