November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Using Gutenberg

by StÃ©phane Ducasse

sure what is your git account. Stef On Nov 1, 2013, at 2:01 PM, phil(a)highoctane.be wrote: > Can you give me write access to the repo? > > Phil > > > On Fri, Nov 1, 2013 at 4:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > the pdf that I sent and that you can find on git hub > > https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english > > down down down at the bottom > > > On Oct 31, 2013, at 7:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > > On 2013-10-31, at 18:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > >> read the latex we documented everything. > > > > which latex file? > > >

Nov. 1, 2013

Re: [Pharo-dev] Questions about Athens

by StÃ©phane Ducasse

Ok now the explanation :) Spec changed recently in 30. 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(a)inria.fr> wrote: > > On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)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(a)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(a)gmail.com> wrote: >> >> >> >> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)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(a)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. >> >> > >

Nov. 1, 2013

Re: [Pharo-dev] Losing instance variable addition

by Tudor Girba

Hi Stef, On Thu, Oct 31, 2013 at 6:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Oct 31, 2013, at 8:25 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I completely disagree with this point of view :). > > We should assume an open world, not a close one. From this point of view, > any part of the system should be extensible by anyone. In most other > languages I know, it is not even possible to extend easily a class with new > functionality. In Pharo we can, and we know it is a powerful mechanism. It > is not the responsibility of the base class to know what extensions are out > there and protect against them. Just like with subclassing, It is in the > responsibility of the extender. > > > + 1 > the runtime should be smart enough to recalculate objects shape. > > We should be able to do the same with state as well. Without this > mechanism, we are forced to put in place clunky dictionary-based mechanism > to support state extension. Essentially, any white-box framework does that. > For example, Morphic does that, FAMIX and Roassal do that, too (and yes, > this is not a bad thing). > > We need this mechanism in the environment, and if I understand Slots > correctly, now we have first class support for it. This also means that > overrides will be easier to deal with, too. Of course, overrides can induce > headaches from time to time, but we should treat these headaches with > proper tools, not by forbidding the world to extend. > > > This is not the same :) > What is not the same? :) By "override" I meant the problem induced by two packages that define the same method, and that are being loaded at the same time. Cheers, Doru > > And if we are at it, we should also be able to extend a class with Traits, > too. > > Cheers, > Doru > > > > > On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> >> On 2013-10-30, at 22:36, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > I don't think there's something to fix. >> > You cannot 'extend' classes belonging to other package in any other way >> > than adding extension methods. >> > Allowing extension of ivars or any other vars by foreign package >> > is road to nowhere. >> > >> > I would not like if shape of my kernel classes depends on what packages >> i load >> > or in what order i loaded them. >> > To me it is clear that if one needs to add/remove/modify instance >> variables >> > of some class, those changes should belong to the package containing >> that class, >> > not some random package. >> >> Exactly, it would cause the same problem as we have with overrides in >> monticello >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 1, 2013

Re: [Pharo-dev] Losing instance variable addition

by Tudor Girba

I agree. I do not see why we make the situation so complicated. Extending a class with state is the same conceptually as is extending it with methods. The same type of problems apply. We can extend a class with methods, and we know it is powerful. Yes, you can have problems with overrides sometimes, but in practice, method extensions collision occurs rarely now. With a little discipline, you can get things to work quite nicely. And again, it is the responsibility of the extender to manage the extensions. Doru On Fri, Nov 1, 2013 at 4:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Oct 31, 2013, at 11:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > Btw, if you remember, i already proposed how to solve 'extending > object's state with arbitrary state' , mainly by changing the object format > to support variable number of key-value properties per object. > > Similar to javascript or self, where you can define a new property on a > per-object basis. > > This is fairly easy to implement, at VM level, just reserve extra field > in object format, > > define the format of key/value dictionary and add primitives to retrieve > and store key-based properties for objects. > > What i like in it, that at language side it is cost nothing: you don't > have to extend > > the language to formally define the slots (but you may, of course), > > and there's nothing preventing you from using private keys and not > giving them away > > to anyone to keep your data private and not exposing it globally (except > from reflection tools i guess). > > And, what is important, you are free to use them or not.. and it costs > almost nothing in terms of performance, and nothing in terms of formalism > and extra rules in language/package/source management etc etc > > you do not need to be at the object level. For me this would be another > level of mess. > > When you think about class extensions we get them because methods are not > in the scope of the their class > so it was easy to define a method into a file that represented another > changeset. > Now we have problem with iv extensions because they are scoped by the > class definition. > > Stef > > > > -- > > Best regards, > > Igor Stasenko. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 1, 2013

Re: [Pharo-dev] [Pharo-users] Pharo Sprint in Buenos Aires Nov 7th

by Guillermo Polito

Hey! I created a doodle :) http://doodle.com/8yhztyhfhapz4rii I think it will be good to know the people that is coming for logistics :). On Tue, Oct 29, 2013 at 10:15 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com>wrote: > Hello, we are organizing a Pharo Sprint in Bs As: > > When: November 7th, starting at 10:00 am > Where: 10 Pines (Av Leandro N. Alem 693 5Â°B) > > >

Nov. 1, 2013

Re: [Pharo-dev] Using Gutenberg

by phil＠highoctane.be

Can you give me write access to the repo? Phil On Fri, Nov 1, 2013 at 4:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > the pdf that I sent and that you can find on git hub > > > https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english > > down down down at the bottom > > > On Oct 31, 2013, at 7:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > > On 2013-10-31, at 18:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > >> read the latex we documented everything. > > > > which latex file? > > >

Nov. 1, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

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(a)inria.fr>wrote: > > On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)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(a)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(a)gmail.com> wrote: >> >>> >>> >>> >>> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)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(a)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. >>> >> >> > >

Nov. 1, 2013

Re: [Pharo-dev] Questions about Athens

by StÃ©phane Ducasse

On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)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(a)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(a)gmail.com> wrote: > > > > On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)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(a)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. > >

Nov. 1, 2013

Looking for camera(wo)man FOSDEM2014 Smalltalk devroom

by Stephan Eggermont

Who is coming to FOSDEM2014 and is willing to help recording one or more sessions at the Smalltalk devroom? Instructions and equipment are provided. Thanks, Stephan Eggermont

Nov. 1, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

Igor I got Athens-Tutorial but it gives me a MNU: AthensViewMorph>>layout: On Fri, Nov 1, 2013 at 10:23 AM, kilon alios <kilon.alios(a)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(a)gmail.com> wrote: > >> >> >> >> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)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(a)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. >> > >

Nov. 1, 2013