- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Losing instance variable addition

by Nicolas Cellier

I agree, on all you said. But sometimes it's also interesting to push the concepts further and explore their benefits/drawbacks before knowing exactly which problems they will solve. A researcher POV rather than an engineer one. I'm an engineer, so I can play advocatus diaboli ;) 2013/10/31 Igor Stasenko <siguctua(a)gmail.com> > > > > On 31 October 2013 22:37, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Hehe, no problem, because any method from SecondThirdPartyRandomExtensio >> nPackage would know which z slot to use. >> Or if you insist on uniqueness, you can invent decorators like well known >> languages ;) >> >> It could get more complex if a FourthThirdPartyExtension would like to >> extend the second extension further and directly access this specific z >> slot ;) >> >> like i said, we can invent anything, put many workaround and/or > conflict-resolution > rules. The main question is it really worth it? > > We can endlessly theorize, how to put such thing and what should be > done/changed, > but first i need a compelling reason, clearly showing the advantage of > having it. > So far, i can only see, that it will bring more problems than solve. > I am in favor of KISS, unless there is big and apparent wins in having > extra complexity. > > >> 2013/10/31 Igor Stasenko <siguctua(a)gmail.com> >> >>> >>> >>> >>> On 31 October 2013 08:25, 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. >>>> >>>> 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. >>>> >>>> And if we are at it, we should also be able to extend a class with >>>> Traits, too. >>>> >>>> it is doable, and easily, as others saying nothing prevents you from >>> saying >>> SomeClass addInstvarNames: 'foo' >>> >>> but the problems in not extending per se, but how you manage it at >>> source level? >>> >>> Like you said, we now having slots.. so >>> then how you think a class definition may look like if some class has >>> extension slots >>> defined by other package? >>> >>> Object subclass: #Point >>> slots: { >>> x, y -> Kernel-Classes >>> z -> ThirdPartyRandomExtensionPackage >>> z -> SecondThirdPartyRandomExtensionPackage >>> z -> ThirdThirdPartyRandomExtensionPackage >>> } >>> >>> i am not against being open. >>> i am against being open to opening can of worms ;) >>> >>> (Apart from completely inadequate proportion between effort to implement >>> such feature and supporting it in many tools (MC etc) comparing to the >>> actual/current need of having it). >>> >>> Clearly, there is no limits in complexity where we can go in attempt to >>> describe our systems with metadata up to tiniest level of detail. >>> Except from some real-world ones: >>> - implementation effort >>> - ease of learn & use >>> - and at last.. sanity :) >>> >>> 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" >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Igor Stasenko

On 31 October 2013 22:37, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hehe, no problem, because any method from SecondThirdPartyRandomExtensio > nPackage would know which z slot to use. > Or if you insist on uniqueness, you can invent decorators like well known > languages ;) > > It could get more complex if a FourthThirdPartyExtension would like to > extend the second extension further and directly access this specific z > slot ;) > > like i said, we can invent anything, put many workaround and/or conflict-resolution rules. The main question is it really worth it? We can endlessly theorize, how to put such thing and what should be done/changed, but first i need a compelling reason, clearly showing the advantage of having it. So far, i can only see, that it will bring more problems than solve. I am in favor of KISS, unless there is big and apparent wins in having extra complexity. > 2013/10/31 Igor Stasenko <siguctua(a)gmail.com> > >> >> >> >> On 31 October 2013 08:25, 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. >>> >>> 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. >>> >>> And if we are at it, we should also be able to extend a class with >>> Traits, too. >>> >>> it is doable, and easily, as others saying nothing prevents you from >> saying >> SomeClass addInstvarNames: 'foo' >> >> but the problems in not extending per se, but how you manage it at source >> level? >> >> Like you said, we now having slots.. so >> then how you think a class definition may look like if some class has >> extension slots >> defined by other package? >> >> Object subclass: #Point >> slots: { >> x, y -> Kernel-Classes >> z -> ThirdPartyRandomExtensionPackage >> z -> SecondThirdPartyRandomExtensionPackage >> z -> ThirdThirdPartyRandomExtensionPackage >> } >> >> i am not against being open. >> i am against being open to opening can of worms ;) >> >> (Apart from completely inadequate proportion between effort to implement >> such feature and supporting it in many tools (MC etc) comparing to the >> actual/current need of having it). >> >> Clearly, there is no limits in complexity where we can go in attempt to >> describe our systems with metadata up to tiniest level of detail. >> Except from some real-world ones: >> - implementation effort >> - ease of learn & use >> - and at last.. sanity :) >> >> 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" >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Oct. 31, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

thanks Igor for the very thorough answer. I took a look at AthensViewScene , I see initializeForNewSession , Smalltalk session and the other state methods, it starts to make sense now. I will get the tutorial and together with Roassal I should be able to make a lot more progress. About OpenGL , no I did not give up too easily. I have been told that OpenGL is complex for a good reason but now I know more about it I just know its the typical C/C++ library, badly designed to the bone. Its a huge pile of mess and the very fact that my macos drivers of my gpu does ( a typical behavior for macos gpu drivers) not report detailed errors it makes it a No Go area for me. Documentation is also a in a very bad state , definitely does not make life easier. My idea was to follow your advise implement OpenVg and then use that as a backend for Athens. But alas at this point I hear OpenGL and just run :D The main problem however was that even if I could use OpenGL I would have to learn also a lot of math to do the OpenVG implementation, So yeah not my cup of tea. I did not expect it to work, I just wanted to learn Nativeboost and NBOpenGL was a good chance to do that. So I realize that the whole deal just was way over my level of skill as a coder. I wanted something a lot simpler. I cant justify wasting months to draw a single curve in the shake of GPU acceleration. Fortunately with Athens I am already able to draw curves, lines, boxes and circles, For me thats a very good start. I dont need 3d graphics at this point, but I may at the distant future. When that time comes then I will consider moving back to NBOpenGL, but not before that. Again thank you all for your help I will keep you posted on my progress. On Thu, Oct 31, 2013 at 9:53 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 31 October 2013 20:01, kilon alios <kilon.alios(a)gmail.com> wrote: > >> Thank you Alexander and Stephane , I did not know that Roassal use >> Athens. This certainly will be helpful for me. >> >> Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I >> learned a lot of things true and yeah I did not know Roassal is using >> NBOpenGL but even if I did as you said opengl is not what I really needed. >> At the time I did not realize the effort to do vector graphics with opengl >> and the whole difficulty of learning the API, now I know I need something >> way more high level for my needs. >> >> About Athens tutorial, I dont know such thing, the only thing I know is >> AthensDemoMorph and the Athens-Examples Package and a video presentation >> that Igor posted way back in vimeo. So no I dont know of such tutorial. >> >> > MCSmalltalkhubRepository > owner: 'Pharo' > project: 'Athens' > user: '' > password: '' > > Load Athens-Tutorial package > Run: > AthensTutorial open > > Wow the guy took 62 K euros and left ? Sorry to hear that :( cant believe >> how people do such things . >> >> no, he didn't. It was a budget allocated for him if he would stay and > work with us. > > >> >> On Thu, Oct 31, 2013 at 7:49 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Hi >>> >>> I created a new subject >>> >>> About the problem to recreate it all it takes is a demo >>> := AthensDemoMorph new openInWorld . It opens the morph with the Athens >>> grey box, I save the image , close pharo, open pharo which reloads the >>> image automagically and BOOM Red Box of Doom :) My other tries also are >>> based on AthensDemoMorph since I cant find documentation to do things >>> differently. >>> >>> So lets get to the questions >>> >>> 1) You say you have morphs using Athens that don't have this problem, >>> care to explain further ? >>> >>> >>> Did you see the tutorial? >>> >>> 2) How do I recreate automatically those surfaces ? >>> >>> 3) Do I need to instruct the image on load to reinitialize those objects >>> ? >>> >>> 4) If yes How I do that ? >>> >>> You say its a major problem but yet its not an Athens bug. I know this >>> is has to do with how image saves live objects and that NB calls are not >>> part of the image hence creating the problem. >>> >>> 5) Are there ways to avoid the problem ? >>> >>> 6) Also why there is a Red Box of Doom in the first place ? >>> >>> >>> >>> 7) Why the debugger is not triggered as it should be ? >>> >>> >>> It is now you should bring the halos and click on debug draw something >>> error >>> >>> >>> 8) Is that critical a failure of Morphic ? >>> >>> 9) Why Athens even though is based largely on Cairo , and taking into >>> consideration the intention to extend to other graphical interfaces, not >>> following the Cairo design more closely so we can use the Cairo tutorials ? >>> >>> >>> Because Athens is not Cairo. Athens is an API so that we can have >>> multiple graphical back-ends in the future. >>> >>> >>> 10) Is the Cairo design so prohibiting / limiting for Athens ? Does >>> Cairo do things so differently than other vector based libraries ? >>> >>> >>> Cairo does not have an OO design from what I know. >>> >>> >>> 11) How important is Athens to Pharo community , meaning further bug >>> fixes, improvements , tutorials etc ? I hear there is an intention to >>> gradual move Morphic to it. Is this true ? >>> >>> >>> Athens is the new canvas and we will rewrite everything to use it. Now >>> Athens will have a default version that is just the default balloon. >>> Now the guy that should have helped us (fernando) left in hurry and we >>> lost the money 62 K Euros of his salary. >>> Igor has been working more than a year in total on Athens, textEditor >>> and others so we will not give up now. >>> >>> >>> I really like Athens, I am asking all these questions because I need to >>> make a fast decision whether I will continue to use Pharo or not for my >>> project. Learning OpenGL and using NBOpenGL produced zero results for me. >>> >>> >>> Did you check Roassal 3d because they forgot to publish the enhancements >>> they did to NBOpenGL >>> >>> I was not even able to create a single triangle. >>> >>> >>> You should look at Roassal 3d because this is working. >>> >>> My gpu driver because of Macos gave me close to zero errors, and Red >>> Box of Doom made it impossible to debug opengl problems. In short close to >>> zero error reporting made it a no go for me. >>> >>> So I fall back at much simpler solutions because I want to create my own >>> GUI API. I see several solutions for this >>> >>> 1) Pharo Athens >>> 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS >>> 3) Python + PyQT + QT >>> >>> I rather stay with Pharo. But I already wasted months of doing nothing >>> and going nowhere with NBOpenGL , I am tried of moving in circles. >>> >>> >>> I'm sure you learned probably a lot. >>> Now for a GUI API may be openGL is not the best to start. What I can >>> tell you is that with Athens we will be able to have the first >>> mix between 3D and 2D vector graphics. >>> >>> I am not frustrated cause I knew when I tried that OpenGL was very hard >>> ( I was warned by several opengl people ) so failure was always an option , >>> but I can no longer justify wasting my time getting nowhere. >>> >>> I dont need much from a graphic lib all I need is >>> >>> a) Stability . If it crashes regularly its no good >>> >>> b) Speed, if moving graphic elements around slows down (anything above >>> 20%) dual cores , its no good >>> >>> c) Basic Feature set like , lines, curves , circles and ellipses , >>> display of raster graphics, simple animations , import export of graphic >>> formats, png , jpg and svg is enough. >>> >>> Looks like Athens satisfies b and c , I am not so sure about a. >>> >>> >>> It is stable. >>> >>> I am trying to understand Athens code from reading it, once again I am a >>> big failure at understanding code. >>> >>> >>> The tutorial is the way to go. Why this is not enough. >>> >>> So is there any hope for someone like me , that he is not a very good >>> coder, he is new to Pharo and he has a simple mind to use Athens to make a >>> basic GUI API ? >>> >>> >>> Yes just focus on Athens. >>> For example extend the >>> >>> >>> >>> On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> On 31 October 2013 16:40, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>>> save the image while the morph is displayed, reload the image and in >>>>> its place there is the big red box with the yellow X , reporting an error >>>>> with Athens. I have reproduced the error on Windows too with the Athens >>>>> examples. I assumed my explanation was clear , I hope its clear now. >>>>> >>>>> >>>> no. not clear. which morph? what class, how you using it etc. >>>> I have morphs which using Athens for drawing and i can save and load >>>> image back and i don't have red squares of death. >>>> >>>> >>>>> This means that its impossible to save an image with a morph using >>>>> Athens displaying and have it reload back when the image is reloaded. >>>>> >>>>> The athens-surface, especially cairo surface is valid only within a >>>> single session. >>>> if you boot new image, you must recreate (or stop using) surface you >>>> used in previous session. >>>> Otherwise you will have red box of doom. >>>> >>>> And while i agree that this is pretty major problem (in terms of making >>>> your morph to be session-aware >>>> and in terms of managing external resources) i am far from calling it a >>>> bug of Athens of any kind per se. >>>> >>>> >>>> >>>>> On Thu, Oct 31, 2013 at 5:05 PM, StÃ©phane Ducasse < >>>>> stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> >>>>>> On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> yes I am aware of the examples already, I am learning from them. >>>>>> Please note I have found a bug with Athens, which looks to me pretty major. >>>>>> If I save a morph using Athens >>>>>> >>>>>> >>>>>> what do you mean save a morph >>>>>> >>>>>> and reload the image, >>>>>> >>>>>> >>>>>> what do you mean? >>>>>> >>>>>> >>>>>> I see the red box of doom. For example trying your example from >>>>>> stackoverflow. Are you aware of this bug ? >>>>>> >>>>>> >>>>>> On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>>> >>>>>>> ah, yes , there's also examples in >>>>>>> Athens-Examples package. >>>>>>> >>>>>>> >>>>>>> On 31 October 2013 01:30, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 30 October 2013 23:02, kilon alios <kilon.alios(a)gmail.com>wrote: >>>>>>>> >>>>>>>>> well I just asked if there is any kind of Documentation about >>>>>>>>> Athens . Or should I just read the code and ask questions ? >>>>>>>>> >>>>>>>>> >>>>>>>> the main source of documentation right now is class comments >>>>>>>> and tutorial. >>>>>>>> I've spent quite of a time commenting the central classes of athens, >>>>>>>> hope that's helpful. >>>>>>>> Of course this does not replacement for a well written docu, and >>>>>>>> that needs to be done. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko < >>>>>>>>> siguctua(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> i hope you satisfied with my answer. >>>>>>>>>> you welcome to ask more, if you not :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 30 October 2013 22:32, dimitris chloupis <thekilon(a)yahoo.co.uk >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, >>>>>>>>>> Igor Stasenko. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >> > > > -- > Best regards, > Igor Stasenko. >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Igor Stasenko

On 31 October 2013 18:49, 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. > > and run into conflict with each and every use of instance where it implies that it has certain shape (or state) but not the other one. IMO, extending original class is anti-modular. It is global, thus anti-modular by definition. I would much more prefer instead of saying: Package A is: { extends: Object withSlot: x } saying: in scope of Package A { Object instances i creating has extra slot: x } because when you making extension to class globally visible, while nobody else is aware of (because it comes only with your package you just loaded), this brings nothing but just problems on many different levels. Aside there's much wiser path (imo), how you can 'extend' the state: by either subclassing or delegation/wrapping/decoration, which helps to clearly separate between what is yours and what is not. 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 :) > > > 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" > > > -- Best regards, Igor Stasenko.

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Nicolas Cellier

Hehe, no problem, because any method from SecondThirdPartyRandomExtensio nPackage would know which z slot to use. Or if you insist on uniqueness, you can invent decorators like well known languages ;) It could get more complex if a FourthThirdPartyExtension would like to extend the second extension further and directly access this specific z slot ;) 2013/10/31 Igor Stasenko <siguctua(a)gmail.com> > > > > On 31 October 2013 08:25, 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. >> >> 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. >> >> And if we are at it, we should also be able to extend a class with >> Traits, too. >> >> it is doable, and easily, as others saying nothing prevents you from > saying > SomeClass addInstvarNames: 'foo' > > but the problems in not extending per se, but how you manage it at source > level? > > Like you said, we now having slots.. so > then how you think a class definition may look like if some class has > extension slots > defined by other package? > > Object subclass: #Point > slots: { > x, y -> Kernel-Classes > z -> ThirdPartyRandomExtensionPackage > z -> SecondThirdPartyRandomExtensionPackage > z -> ThirdThirdPartyRandomExtensionPackage > } > > i am not against being open. > i am against being open to opening can of worms ;) > > (Apart from completely inadequate proportion between effort to implement > such feature and supporting it in many tools (MC etc) comparing to the > actual/current need of having it). > > Clearly, there is no limits in complexity where we can go in attempt to > describe our systems with metadata up to tiniest level of detail. > Except from some real-world ones: > - implementation effort > - ease of learn & use > - and at last.. sanity :) > > 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" >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Igor Stasenko

On 31 October 2013 08:25, 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. > > 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. > > And if we are at it, we should also be able to extend a class with Traits, > too. > > it is doable, and easily, as others saying nothing prevents you from saying SomeClass addInstvarNames: 'foo' but the problems in not extending per se, but how you manage it at source level? Like you said, we now having slots.. so then how you think a class definition may look like if some class has extension slots defined by other package? Object subclass: #Point slots: { x, y -> Kernel-Classes z -> ThirdPartyRandomExtensionPackage z -> SecondThirdPartyRandomExtensionPackage z -> ThirdThirdPartyRandomExtensionPackage } i am not against being open. i am against being open to opening can of worms ;) (Apart from completely inadequate proportion between effort to implement such feature and supporting it in many tools (MC etc) comparing to the actual/current need of having it). Clearly, there is no limits in complexity where we can go in attempt to describe our systems with metadata up to tiniest level of detail. Except from some real-world ones: - implementation effort - ease of learn & use - and at last.. sanity :) 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" > -- Best regards, Igor Stasenko.

Oct. 31, 2013

Re: [Pharo-dev] Questions about Athens

by Igor Stasenko

On 31 October 2013 20:01, kilon alios <kilon.alios(a)gmail.com> wrote: > Thank you Alexander and Stephane , I did not know that Roassal use Athens. > This certainly will be helpful for me. > > Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I > learned a lot of things true and yeah I did not know Roassal is using > NBOpenGL but even if I did as you said opengl is not what I really needed. > At the time I did not realize the effort to do vector graphics with opengl > and the whole difficulty of learning the API, now I know I need something > way more high level for my needs. > > About Athens tutorial, I dont know such thing, the only thing I know is > AthensDemoMorph and the Athens-Examples Package and a video presentation > that Igor posted way back in vimeo. So no I dont know of such tutorial. > > MCSmalltalkhubRepository owner: 'Pharo' project: 'Athens' user: '' password: '' Load Athens-Tutorial package Run: AthensTutorial open Wow the guy took 62 K euros and left ? Sorry to hear that :( cant believe > how people do such things . > > no, he didn't. It was a budget allocated for him if he would stay and work with us. > > On Thu, Oct 31, 2013 at 7:49 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi >> >> I created a new subject >> >> About the problem to recreate it all it takes is a demo >> := AthensDemoMorph new openInWorld . It opens the morph with the Athens >> grey box, I save the image , close pharo, open pharo which reloads the >> image automagically and BOOM Red Box of Doom :) My other tries also are >> based on AthensDemoMorph since I cant find documentation to do things >> differently. >> >> So lets get to the questions >> >> 1) You say you have morphs using Athens that don't have this problem, >> care to explain further ? >> >> >> Did you see the tutorial? >> >> 2) How do I recreate automatically those surfaces ? >> >> 3) Do I need to instruct the image on load to reinitialize those objects >> ? >> >> 4) If yes How I do that ? >> >> You say its a major problem but yet its not an Athens bug. I know this >> is has to do with how image saves live objects and that NB calls are not >> part of the image hence creating the problem. >> >> 5) Are there ways to avoid the problem ? >> >> 6) Also why there is a Red Box of Doom in the first place ? >> >> >> >> 7) Why the debugger is not triggered as it should be ? >> >> >> It is now you should bring the halos and click on debug draw something >> error >> >> >> 8) Is that critical a failure of Morphic ? >> >> 9) Why Athens even though is based largely on Cairo , and taking into >> consideration the intention to extend to other graphical interfaces, not >> following the Cairo design more closely so we can use the Cairo tutorials ? >> >> >> Because Athens is not Cairo. Athens is an API so that we can have >> multiple graphical back-ends in the future. >> >> >> 10) Is the Cairo design so prohibiting / limiting for Athens ? Does >> Cairo do things so differently than other vector based libraries ? >> >> >> Cairo does not have an OO design from what I know. >> >> >> 11) How important is Athens to Pharo community , meaning further bug >> fixes, improvements , tutorials etc ? I hear there is an intention to >> gradual move Morphic to it. Is this true ? >> >> >> Athens is the new canvas and we will rewrite everything to use it. Now >> Athens will have a default version that is just the default balloon. >> Now the guy that should have helped us (fernando) left in hurry and we >> lost the money 62 K Euros of his salary. >> Igor has been working more than a year in total on Athens, textEditor and >> others so we will not give up now. >> >> >> I really like Athens, I am asking all these questions because I need to >> make a fast decision whether I will continue to use Pharo or not for my >> project. Learning OpenGL and using NBOpenGL produced zero results for me. >> >> >> Did you check Roassal 3d because they forgot to publish the enhancements >> they did to NBOpenGL >> >> I was not even able to create a single triangle. >> >> >> You should look at Roassal 3d because this is working. >> >> My gpu driver because of Macos gave me close to zero errors, and Red Box >> of Doom made it impossible to debug opengl problems. In short close to zero >> error reporting made it a no go for me. >> >> So I fall back at much simpler solutions because I want to create my own >> GUI API. I see several solutions for this >> >> 1) Pharo Athens >> 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS >> 3) Python + PyQT + QT >> >> I rather stay with Pharo. But I already wasted months of doing nothing >> and going nowhere with NBOpenGL , I am tried of moving in circles. >> >> >> I'm sure you learned probably a lot. >> Now for a GUI API may be openGL is not the best to start. What I can tell >> you is that with Athens we will be able to have the first >> mix between 3D and 2D vector graphics. >> >> I am not frustrated cause I knew when I tried that OpenGL was very hard ( >> I was warned by several opengl people ) so failure was always an option , >> but I can no longer justify wasting my time getting nowhere. >> >> I dont need much from a graphic lib all I need is >> >> a) Stability . If it crashes regularly its no good >> >> b) Speed, if moving graphic elements around slows down (anything above >> 20%) dual cores , its no good >> >> c) Basic Feature set like , lines, curves , circles and ellipses , >> display of raster graphics, simple animations , import export of graphic >> formats, png , jpg and svg is enough. >> >> Looks like Athens satisfies b and c , I am not so sure about a. >> >> >> It is stable. >> >> I am trying to understand Athens code from reading it, once again I am a >> big failure at understanding code. >> >> >> The tutorial is the way to go. Why this is not enough. >> >> So is there any hope for someone like me , that he is not a very good >> coder, he is new to Pharo and he has a simple mind to use Athens to make a >> basic GUI API ? >> >> >> Yes just focus on Athens. >> For example extend the >> >> >> >> On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> On 31 October 2013 16:40, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> save the image while the morph is displayed, reload the image and in >>>> its place there is the big red box with the yellow X , reporting an error >>>> with Athens. I have reproduced the error on Windows too with the Athens >>>> examples. I assumed my explanation was clear , I hope its clear now. >>>> >>>> >>> no. not clear. which morph? what class, how you using it etc. >>> I have morphs which using Athens for drawing and i can save and load >>> image back and i don't have red squares of death. >>> >>> >>>> This means that its impossible to save an image with a morph using >>>> Athens displaying and have it reload back when the image is reloaded. >>>> >>>> The athens-surface, especially cairo surface is valid only within a >>> single session. >>> if you boot new image, you must recreate (or stop using) surface you >>> used in previous session. >>> Otherwise you will have red box of doom. >>> >>> And while i agree that this is pretty major problem (in terms of making >>> your morph to be session-aware >>> and in terms of managing external resources) i am far from calling it a >>> bug of Athens of any kind per se. >>> >>> >>> >>>> On Thu, Oct 31, 2013 at 5:05 PM, StÃ©phane Ducasse < >>>> stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>> On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios(a)gmail.com> >>>>> wrote: >>>>> >>>>> yes I am aware of the examples already, I am learning from them. >>>>> Please note I have found a bug with Athens, which looks to me pretty major. >>>>> If I save a morph using Athens >>>>> >>>>> >>>>> what do you mean save a morph >>>>> >>>>> and reload the image, >>>>> >>>>> >>>>> what do you mean? >>>>> >>>>> >>>>> I see the red box of doom. For example trying your example from >>>>> stackoverflow. Are you aware of this bug ? >>>>> >>>>> >>>>> On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>> >>>>>> ah, yes , there's also examples in >>>>>> Athens-Examples package. >>>>>> >>>>>> >>>>>> On 31 October 2013 01:30, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> On 30 October 2013 23:02, kilon alios <kilon.alios(a)gmail.com> wrote: >>>>>>> >>>>>>>> well I just asked if there is any kind of Documentation about >>>>>>>> Athens . Or should I just read the code and ask questions ? >>>>>>>> >>>>>>>> >>>>>>> the main source of documentation right now is class comments >>>>>>> and tutorial. >>>>>>> I've spent quite of a time commenting the central classes of athens, >>>>>>> hope that's helpful. >>>>>>> Of course this does not replacement for a well written docu, and >>>>>>> that needs to be done. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua(a)gmail.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> i hope you satisfied with my answer. >>>>>>>>> you welcome to ask more, if you not :) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 30 October 2013 22:32, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, >>>>>>>>> Igor Stasenko. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> > -- Best regards, Igor Stasenko.

Oct. 31, 2013

Re: [Pharo-dev] Formatting dates

by blake

Thanks, everybody! On Thu, Oct 31, 2013 at 1:00 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Closest match is with the Printf package ( > http://www.squeaksource.com/Printf) > > example: > > now := DateAndTime now. > filename := '%s-%04d%02d%02d_%02d%02d.ston' printf: { self name. now year. > now month. now dayOfMonth. now hour. now minutes.}. > > I am coming from C, so, yes, I like printf. (Can't help thinking about > PRINT USING "#####.##" of old :-) > http://www.colorcomputerarchive.com/coco/Documents/Manuals/Hardware/Getting… p187 > - 1983) > > Phil > > > > On Wed, Oct 30, 2013 at 11:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> >> On 30 Oct 2013, at 22:46, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> > Why not a more discriminating example, like '19991231â? >> >> From the class comment: >> >> â¦ >> You instanciate me by specifying the textual format by example, based on >> a #reference timetamp. >> >> Each component of the example representation is numbered from largest to >> smallest unit, 1=year, 2=month, 3=dayInMonth, 4=hour (16 in 24 hour >> format), 5=minute and 6=second, as in the ISO representation: >> 2001-02-03T16:05:06Z which is a Saterday. Example format strings can be >> found in my class accessing protocol or in the unit tests. >> â¦ >> >> But of course, internally there is less magic: it are just specific >> keys/tokens that are recognised ;-) The example is kind of compiled though >> to make it more efficient should you reuse the format. >> >> > 2013/10/30 Sven Van Caekenberghe <sven(a)stfx.eu> >> > Hi Blake, >> > >> > On 30 Oct 2013, at 21:55, blake <dsblakewatson(a)gmail.com> wrote: >> > >> > > Heya, guys-- >> > > >> > > Converting a Ruby program to Pharo, and one of the things this >> program does is write a file out by date. The format is "yyyymmdd" (which >> is my preferred naming convention). In Ruby I have: >> > > >> > > "%04d" % d.year + "%02d" % d.month + "%02d" % d.day >> > > >> > > In Smalltalk, the closest I can seem to get to this is: >> > > >> > > d year asString, (d monthIndex asString padLeftTo: 2 with: $0), (d >> dayOfMonth asString padLeftTo: 2 with: $0) >> > > >> > > ...which seems sort verbose. Anyone have any more elegant solutions? >> > >> > Using the âby exampleâ formatter/parser that is part of the ZTimestamp >> package (can be loaded using the Configuration Browser), you could say: >> > >> > (ZTimestampFormat fromString: '20010203') format: Date today. >> > >> > Although it is called ZTimestampFormat, it can actually work with Date, >> Time, DateAndTime as well. >> > >> > Sven >> > >> >> >> >

Oct. 31, 2013

Re: [Pharo-dev] Questions about Athens

by Igor Stasenko

On 31 October 2013 18:24, kilon alios <kilon.alios(a)gmail.com> wrote: > I created a new subject > > About the problem to recreate it all it takes is a demo := AthensDemoMorph > new openInWorld . It opens the morph with the Athens grey box, I save the > image , close pharo, open pharo which reloads the image automagically and > BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph > since I cant find documentation to do things differently. > > That one is bad, it does not having session management code. Perhaps because the code there was authored before i figured what is most convenient pattern to deal with it, neither i thought about that at all, because it was too early to think about it. At that stage i was more concerned about that framework is capable of rendering stuff correctly. (see my other reply about that). > So lets get to the questions > > 1) You say you have morphs using Athens that don't have this problem, care > to explain further ? > > yes, there is number of morphs which correctly implement session-aware resource management, which you need when working with surfaces. AthensSceneView, AthensWrapMorph The problem is that right now it is a little incursions (since Athens does not completely replaces old Canvas and runs in parallel to it), and there is no globals, like Display which manages that. This code had to be added at one day, but not before we figure, how we can deliver rendered data directly to OS-level window bypassing Form(s) and unnecessary bit copying here and there between number of double-triple-quadruple buffering which stands between Morphic and OS-level screen, which greatly hinders the screen update performance. (or at least figure our migration plan/path). But for that we also must cut out parts in VM and move responsibility for creating OS-level window(s) into image, not VM. The limitations, which we currently having in VM greatly cripples the number of choices of what can be done using Pharo for making desktop-level application. But it is more general problem, and there's nothing in Athens to blame for it. 2) How do I recreate automatically those surfaces ? > > 3) Do I need to instruct the image on load to reinitialize those objects ? > > 4) If yes How I do that ? > > see how i did that in AthensSceneView, AthensWrapMorph > You say its a major problem but yet its not an Athens bug. I know this is > has to do with how image saves live objects and that NB calls are not part > of the image hence creating the problem. > > 5) Are there ways to avoid the problem ? > > yes, use Smalltalk session object to check if session is changed before any attempt of using external resource(s). > 6) Also why there is a Red Box of Doom in the first place ? > > 7) Why the debugger is not triggered as it should be ? > > It is a general feature of Morphic: if there's an error during morph's drawing it renders it as red box, but not opens a debugger. because opening debugger implies that you will need to render debugger window, but if that code raising an error, you will enter endless recursion. If you don't like it, you can disable it in Morph>>fullDrawOn: aCanvas (and then try to put a mistake in any morph's rendering code.. but don't say i didn't warned you ;) 8) Is that critical a failure of Morphic ? > > It is not a failure, the red box is the only sane way how to keep things running, even if there's error(s) in code. But sometimes even that doesn't helps. Other choice would be to just leave to OS, because at that stage UI will be unresponsive anyways, but that will be even worse, isn't? > 9) Why Athens even though is based largely on Cairo , and taking into > consideration the intention to extend to other graphical interfaces, not > following the Cairo design more closely so we can use the Cairo tutorials ? > > The biggest source for design choices is not Cairo. But OpenVG standard. Cairo was easy to reach, low-hanging fruit which we grasp. A more expanded answer as for why Athens is not copy-paste of Cairo, you can read here: http://computeradventures.wordpress.com/2012/03/07/athens-a-first-babysteps/ [[ In other words, give me 1 week, a lump sum of money, and after 2 weeks [image: ;)] i will deliver you a binding to any C library you want. But do not expect that it will be much easier to use it, only because you can access it in smalltalk. This is because exposing a non-object oriented library in smalltalk does not automagically makes it by a bit more object oriented, especially in terms of smalltalk, not in terms of C++ [image: :)] . ]] 10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo > do things so differently than other vector based libraries ? > > Most of them providing more or less same set of features. But each of them has own API and own idiosyncrasies to deal with, and Athens here to serve for hiding unnecessary details from users and provide a consistent object-oriented API. > 11) How important is Athens to Pharo community , meaning further bug > fixes, improvements , tutorials etc ? I hear there is an intention to > gradual move Morphic to it. Is this true ? > > Yes, it is our future. > I really like Athens, I am asking all these questions because I need to > make a fast decision whether I will continue to use Pharo or not for my > project. Learning OpenGL and using NBOpenGL produced zero results for me. I > was not even able to create a single triangle. My gpu driver because of > Macos gave me close to zero errors, and Red Box of Doom made it impossible > to debug opengl problems. In short close to zero error reporting made it a > no go for me. > > Sounds like you surrendered too quickly. :) I know multiple people who managed to do things with it, like importing 3d models and rendering them. But sure thing, it is not easy and requires a lot of effort and broad knowledge in multiple areas and abilities to learn & search for examples and docs and understanding the mechanics behind everything. > So I fall back at much simpler solutions because I want to create my own > GUI API. I see several solutions for this > > 1) Pharo Athens > 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS > 3) Python + PyQT + QT > > I rather stay with Pharo. But I already wasted months of doing nothing and > going nowhere with NBOpenGL , I am tried of moving in circles. I am not > frustrated cause I knew when I tried that OpenGL was very hard ( I was > warned by several opengl people ) so failure was always an option , but I > can no longer justify wasting my time getting nowhere. > > you can ask Alex, who has working examples of opengl. Roassal 3D. > I dont need much from a graphic lib all I need is > > a) Stability . If it crashes regularly its no good > > b) Speed, if moving graphic elements around slows down (anything above > 20%) dual cores , its no good > > c) Basic Feature set like , lines, curves , circles and ellipses , > display of raster graphics, simple animations , import export of graphic > formats, png , jpg and svg is enough. > > Looks like Athens satisfies b and c , I am not so sure about a. > > I dealing with Athens for... ?last year? almost every day during my work.. don't have much problems here. And that would be my top-priority taks, if it would be a problem, because it would be blocking my own work. > I am trying to understand Athens code from reading it, once again I am a > big failure at understanding code. > > ask questions. I will gladly help understanding. > So is there any hope for someone like me , that he is not a very good > coder, he is new to Pharo and he has a simple mind to use Athens to make a > basic GUI API ? > > Definitely yes :) > On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> On 31 October 2013 16:40, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> save the image while the morph is displayed, reload the image and in its >>> place there is the big red box with the yellow X , reporting an error with >>> Athens. I have reproduced the error on Windows too with the Athens >>> examples. I assumed my explanation was clear , I hope its clear now. >>> >>> >> no. not clear. which morph? what class, how you using it etc. >> I have morphs which using Athens for drawing and i can save and load >> image back and i don't have red squares of death. >> >> >>> This means that its impossible to save an image with a morph using >>> Athens displaying and have it reload back when the image is reloaded. >>> >>> The athens-surface, especially cairo surface is valid only within a >> single session. >> if you boot new image, you must recreate (or stop using) surface you used >> in previous session. >> Otherwise you will have red box of doom. >> >> And while i agree that this is pretty major problem (in terms of making >> your morph to be session-aware >> and in terms of managing external resources) i am far from calling it a >> bug of Athens of any kind per se. >> >> >> >>> On Thu, Oct 31, 2013 at 5:05 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>> yes I am aware of the examples already, I am learning from them. Please >>>> note I have found a bug with Athens, which looks to me pretty major. If I >>>> save a morph using Athens >>>> >>>> >>>> what do you mean save a morph >>>> >>>> and reload the image, >>>> >>>> >>>> what do you mean? >>>> >>>> >>>> I see the red box of doom. For example trying your example from >>>> stackoverflow. Are you aware of this bug ? >>>> >>>> >>>> On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> ah, yes , there's also examples in >>>>> Athens-Examples package. >>>>> >>>>> >>>>> On 31 October 2013 01:30, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> On 30 October 2013 23:02, kilon alios <kilon.alios(a)gmail.com> wrote: >>>>>> >>>>>>> well I just asked if there is any kind of Documentation about Athens >>>>>>> . Or should I just read the code and ask questions ? >>>>>>> >>>>>>> >>>>>> the main source of documentation right now is class comments >>>>>> and tutorial. >>>>>> I've spent quite of a time commenting the central classes of athens, >>>>>> hope that's helpful. >>>>>> Of course this does not replacement for a well written docu, and that >>>>>> needs to be done. >>>>>> >>>>>> >>>>>>> >>>>>>> On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>>>> >>>>>>>> i hope you satisfied with my answer. >>>>>>>> you welcome to ask more, if you not :) >>>>>>>> >>>>>>>> >>>>>>>> On 30 October 2013 22:32, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Oct. 31, 2013

Re: [Pharo-dev] Add HTTPRequest plugin to CI

by Camillo Bruni

On 2013-10-31, at 19:55, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Is it OK/possible to add this plugin to Jenkins: > > https://wiki.jenkins-ci.org/display/JENKINS/HTTP+Request+Plugin >From what I get this plugin is used to make http request from jenkins. You can easily do that with pharo ;) or bash scripts. I always prefer to not use any jenkins specific stuff, since you cannot just copy the script and run it locally. Please see below, if this is not what you need, I can install the plugin.. > With it a person could, if they wanted, set the Inria Jenkins to monitor some smalltalk mc repo urls and then trigger a github hook which would start travis-ci building a Configuration across several platforms. Maybe I misunderstood, but you want to monitor an external resource from jenkins, we use the [URLTrigger] plugin for that, see https://ci.inria.fr/pharo-contribution/job/AsmJit/configure > If you look at this repo: > > https://github.com/pdebruic/ConfigurationOfSeaside3 > > It contains the minimum needed to have Travis-CI build Seaside on Squeak, Pharo (1.4 & 2) , and Gemstone. To trigger the build you can either push a git commit to github or send a POST github as described here: > > http://developer.github.com/v3/repos/hooks/#test-a-push-hook > > I'd prefer to send a POST because it seems easier than coordinating a git push from the Inria CI. > > If its not possible to add that then I can just get a VPS for $1/month and run my own jenkins on it. But this technique may be generally useful. You can just setup a repository polling see https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/configure

Oct. 31, 2013