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@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@gmail.com> wrote:
On 1 November 2013 14:32, Stéphane Ducasse <stephane.ducasse@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@inria.fr> wrote:
On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios@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@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@gmail.com>wrote:
On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel@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@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.