March 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40582 Home: https://github.com/pharo-project/pharo-core

March 25, 2015

[pharo-project/pharo-core] 92dba9: 40582

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 92dba9d435851555f71526d9005288e023fecad7 https://github.com/pharo-project/pharo-core/commit/92dba9d435851555f71526d9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-25 (Wed, 25 Mar 2015) Changed paths: M AST-Core.package/NumberParser.class/instance/parsing-private/makeIntegerOrScaledInteger.st A AST-Core.package/NumberParser.class/instance/parsing-private/makeIntegerOrScaledIntegerOrFloat.st M AST-Core.package/NumberParser.class/instance/parsing-public/nextNumber.st M AST-Core.package/NumberParser.class/instance/parsing-public/nextNumberBase_.st A AST-Tests-Core.package/NumberParserTest.class/instance/tests - Float/testIntegerWithNegExponentIsAFloat.st M Morphic-Core.package/PasteUpMorph.class/instance/event handling/windowEvent_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script581.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script582.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40581.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40582.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40582 13761 Fraction floating pointer cannot be debugged https://pharo.fogbugz.com/f/cases/13761 15215 Prevent the World locking due to multiple modal dialogs open https://pharo.fogbugz.com/f/cases/15215 http://files.pharo.org/image/40/40582.zip

March 25, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Ben Coman

On Wed, Mar 25, 2015 at 6:08 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I have to confess I did not understand this obsession of implementing > everything in Pharo when I joined coming from python. But now I find this > obsession too infectious to resist :) > That's why its impossible to convert people via HN and Reddit. Like > skydiving (I imagine), it seems like a really bad idea to leave the safety > of ill-conceived vendor-supplied tools until you jump and actually live it > for yourself for long enough to realize what freedom feels like! One of the things that drew me to do the Delay refactoring, is simply that I could. That is, I was amazed that I could dig so deep so easily, see a path to improvement and effect change at a fundamental level. Excepting complexities with the CI due to "changing the wheels on the car at 100km/h" (and one slip), it seems to have gone reasonably smoothly. That sense of mastery is seductive. cheers -ben

March 25, 2015

Latest VM doesn't have Wheel changes

by Sean P. DeNigris

I see them in the source zip right alongside the app on Jenkins, and the changes worked as expected on my Mac when I built by hand. I even kicked off another build, but #419 didn't seem to have the changes either... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Latest-VM-doesn-t-have-Wheel-changes-tp4814972.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

Hi, On Wed, Mar 25, 2015 at 12:17 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-03-24 22:48 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi Torsten, >> >> Thanks for the long email. The first part summarizes the situation >> reasonably well, except that you are putting the same pot <example> >> annotated methods and methods having example* selectors. To try to clear >> the water I thought I would answer with an almost equally long email :). >> >> I am not trying to redefine anything. We had the discussion about >> renaming the original <gtExample> into <example> some months ago and since >> then we only used <example> to mean what my description is: an initialized >> object. There are indeed many methods named example* that have a loose >> meaning that is different than the clearly defined <example> methods, but >> that does not mean that <example> was ever used for anything else than what >> my definition. >> > > I must admit I misunderstood that discussion, I thought it was about a the > GLMExamplesBrowser not the inspector. I thought the tag will be used > to create a list of examples and selecting the method will run the method. > > There was a screenshot of the inspector in it :). > > >> >> In the Pharo image there are current 96 methods annotated with <example> >> or <example:>, and in fact, the only one method of these that does not >> preserve the meaning of <example> appeared in the recently integrated >> Athens version 3.1. This method executes a demo that requires a key press >> to end. >> >> So, who would you say is changing the meaning of an existing state of >> facts? :) >> > > I think he is talkting about the meaning of "example" in the "method > name". This exists much longer than the "gtExample pragmas". > We have many exampleXXX methods in the image that actually start something > (the widget examples for instance). So it is a bit confusing that > the <example> pragma only provides some data. > Yes, there are many example* methods, often with different interpretations. That is why, I specifically mentioned the distinction between the #example* selectors and <example> pragmas multiple times. As for Nautilus dealing with fuzzy semantics, my choice would be to only support <example>, or at least when we have <example> to inspect the result rather than just to execute it. > How about removing the <example> pragma from the runDemo method in > VGTigerDemo and rename it to > example > > and move this discussion after the release? > Sure. Or we can have <script> which I already committed, but I am fine with the comment. > > There is great value that comes from the simple and clearly defined >> concept of <example>. >> > > I think this discussion shows that the purpose of the <example> pragma is > not "a simple and clearly defined concept" :) > I think the concept is straightforward enough that it could be nicely summarized both by you and by Torsten :). I think it's not the concept that is the problem but that we historically built tools to deal with fuzzy semantics and now it's hard to let go of them :) Cheers, Doru > Nicolai > > > >> Cheers, >> Doru >> >> >> >> On Tue, Mar 24, 2015 at 8:56 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> Hi Tudor and all, >>> >>> to understand the issue one has to know: >>> >>> ------------------------------------------------------------------------------------------ >>> There are two pragmas in Pharo 4 that were already introduced and >>> integrated: >>> >>> <script> / <script:> - one can use this to mark methods (of any >>> signature) >>> as development scripts. One can use it on >>> instance side >>> and an class side methods to run the >>> method or some >>> code while developing without having to >>> leave the browser. >>> After completion Nautilus shows that the >>> method finished >>> >>> Think of a class >>> "MyKillerProjectDatabase" with a class >>> side method "start". >>> You can click this to run - but it does >>> not serve as an >>> example. A script is just "SOMETHING TO >>> RUN". The code >>> of the script may be too easy or to >>> complicated to serve >>> as an example. >>> >>> See also #14647, #14747 and #14995 for >>> details. >>> >>> <example> - Nautilus in the past already honored >>> class side exampleXXX >>> methods to have a "play" icon to easily >>> visually see examples >>> and just run them. >>> >>> With the <example> pragma one can >>> explicitly mark a method as >>> an example method and we do not have to >>> rely on the method name. >>> So we can use #tryThisOutForExample as >>> selector name as well now. >>> >>> It also allows to search for examples, >>> build an example browser >>> for newbees, ... >>> >>> An example shows the usage of a class or >>> code (usually to get >>> an initial idea). The pragma also only >>> works on class side methods. >>> >>> Think of existing classes like >>> EditableList or WidgetExamples >>> that provide example methods starting >>> with exampleXXX. >>> The user sees in the browser directly >>> that this is an example he >>> can run or look at to understand the >>> details because the author >>> offered it as "SOMETHING TO LEARN FROM". >>> >>> See also >>> #14646 and #15225 for details >>> >>> So (even only at the second look) there is a distinction between a >>> "script" and an "example". >>> Being a script does not automagically make a method an example. And yes: >>> a method can also >>> be both and both pragmas can be used. >>> >>> The history of these two is explained in >>> https://pharo.fogbugz.com/f/cases/15225/useless-play-icon-in-nautilus >>> and I already use this in several projects. >>> >>> >>> -------------------------------------------------------------------------------------------- >>> >>> Now it looks like Tudor is in need of a pragma for GT tools to provide >>> "example data". >>> >>> @Tudor: >>> I do not understand why you now abuse/try to redefine the meaning of >>> this existing <example> pragma >>> for your special purposes/needs or try to exchange one against the other >>> as in new issue #15229. >>> >>> According to your own comment in issue #15225 your definition of an >>> "example" is something >>> "to offer an initialized object that can be used for documentation or >>> testing purposes." >>> >>> I have to strongly disagree on this as this is ONLY TRUE FOR A FEW >>> CASES. Look at our image, look at >>> how people write example (methods): >>> >>> NOT ALL class side example methods necessarily return an initialized >>> objects but are still examples. >>> I already explained in the above issue that there are lots of example >>> methods that one just run >>> (either from the comment or from Nautilus icon) like >>> EditableListExampel(class)>>example, ... >>> They DO NOT return an initialized instance. >>> >>> Look at the "examples" in class WidgetExamples or others. None of them >>> provide an initialized instance! >>> >>> So the right definition for an "example" is: >>> "to offer runnable code that can be used for documentation or testing >>> purposes." >>> >>> >>> So PLEASE if you are in need of such a new thing where only initialized >>> instances are returned from >>> code then DO NOT REDEFINE existing and used pragmas like the integrated >>> <example> pragma. >>> >>> PLEASE use an OWN NEW PRAGMA for GT purposes like <exampleData>, >>> <exampleInstance>, <gtExampleInstance> >>> or whatever. I would also find an "exampleInstance" pragma name then >>> more intention revealing. >>> >>> Thanks a lot in in advance! >>> >>> Bye >>> T. >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Nicolai Hess

2015-03-24 22:48 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Torsten, > > Thanks for the long email. The first part summarizes the situation > reasonably well, except that you are putting the same pot <example> > annotated methods and methods having example* selectors. To try to clear > the water I thought I would answer with an almost equally long email :). > > I am not trying to redefine anything. We had the discussion about renaming > the original <gtExample> into <example> some months ago and since then we > only used <example> to mean what my description is: an initialized object. > There are indeed many methods named example* that have a loose meaning that > is different than the clearly defined <example> methods, but that does not > mean that <example> was ever used for anything else than what my definition. > I must admit I misunderstood that discussion, I thought it was about a the GLMExamplesBrowser not the inspector. I thought the tag will be used to create a list of examples and selecting the method will run the method. > > In the Pharo image there are current 96 methods annotated with <example> > or <example:>, and in fact, the only one method of these that does not > preserve the meaning of <example> appeared in the recently integrated > Athens version 3.1. This method executes a demo that requires a key press > to end. > > So, who would you say is changing the meaning of an existing state of > facts? :) > I think he is talkting about the meaning of "example" in the "method name". This exists much longer than the "gtExample pragmas". We have many exampleXXX methods in the image that actually start something (the widget examples for instance). So it is a bit confusing that the <example> pragma only provides some data. How about removing the <example> pragma from the runDemo method in VGTigerDemo and rename it to example and move this discussion after the release? There is great value that comes from the simple and clearly defined > concept of <example>. > I think this discussion shows that the purpose of the <example> pragma is not "a simple and clearly defined concept" :) Nicolai > Cheers, > Doru > > > > On Tue, Mar 24, 2015 at 8:56 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi Tudor and all, >> >> to understand the issue one has to know: >> >> ------------------------------------------------------------------------------------------ >> There are two pragmas in Pharo 4 that were already introduced and >> integrated: >> >> <script> / <script:> - one can use this to mark methods (of any >> signature) >> as development scripts. One can use it on >> instance side >> and an class side methods to run the >> method or some >> code while developing without having to >> leave the browser. >> After completion Nautilus shows that the >> method finished >> >> Think of a class "MyKillerProjectDatabase" >> with a class >> side method "start". >> You can click this to run - but it does >> not serve as an >> example. A script is just "SOMETHING TO >> RUN". The code >> of the script may be too easy or to >> complicated to serve >> as an example. >> >> See also #14647, #14747 and #14995 for >> details. >> >> <example> - Nautilus in the past already honored class >> side exampleXXX >> methods to have a "play" icon to easily >> visually see examples >> and just run them. >> >> With the <example> pragma one can >> explicitly mark a method as >> an example method and we do not have to >> rely on the method name. >> So we can use #tryThisOutForExample as >> selector name as well now. >> >> It also allows to search for examples, >> build an example browser >> for newbees, ... >> >> An example shows the usage of a class or >> code (usually to get >> an initial idea). The pragma also only >> works on class side methods. >> >> Think of existing classes like >> EditableList or WidgetExamples >> that provide example methods starting with >> exampleXXX. >> The user sees in the browser directly that >> this is an example he >> can run or look at to understand the >> details because the author >> offered it as "SOMETHING TO LEARN FROM". >> >> See also >> #14646 and #15225 for details >> >> So (even only at the second look) there is a distinction between a >> "script" and an "example". >> Being a script does not automagically make a method an example. And yes: >> a method can also >> be both and both pragmas can be used. >> >> The history of these two is explained in >> https://pharo.fogbugz.com/f/cases/15225/useless-play-icon-in-nautilus >> and I already use this in several projects. >> >> >> -------------------------------------------------------------------------------------------- >> >> Now it looks like Tudor is in need of a pragma for GT tools to provide >> "example data". >> >> @Tudor: >> I do not understand why you now abuse/try to redefine the meaning of this >> existing <example> pragma >> for your special purposes/needs or try to exchange one against the other >> as in new issue #15229. >> >> According to your own comment in issue #15225 your definition of an >> "example" is something >> "to offer an initialized object that can be used for documentation or >> testing purposes." >> >> I have to strongly disagree on this as this is ONLY TRUE FOR A FEW CASES. >> Look at our image, look at >> how people write example (methods): >> >> NOT ALL class side example methods necessarily return an initialized >> objects but are still examples. >> I already explained in the above issue that there are lots of example >> methods that one just run >> (either from the comment or from Nautilus icon) like >> EditableListExampel(class)>>example, ... >> They DO NOT return an initialized instance. >> >> Look at the "examples" in class WidgetExamples or others. None of them >> provide an initialized instance! >> >> So the right definition for an "example" is: >> "to offer runnable code that can be used for documentation or testing >> purposes." >> >> >> So PLEASE if you are in need of such a new thing where only initialized >> instances are returned from >> code then DO NOT REDEFINE existing and used pragmas like the integrated >> <example> pragma. >> >> PLEASE use an OWN NEW PRAGMA for GT purposes like <exampleData>, >> <exampleInstance>, <gtExampleInstance> >> or whatever. I would also find an "exampleInstance" pragma name then more >> intention revealing. >> >> Thanks a lot in in advance! >> >> Bye >> T. >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by kilon alios

Tudor , I am only amazed how much you guys accomplish with so limited resources. I may not agree with some of the choices but I am very happy with the progress Pharo is making and glad I stick around. If the community is not ready for a roadmap , so be it. You will be ready when you will be ready.I do think however that more the community grows coordinating effort will become a key issue. I do agree that things look very encouraging and I trust the community to move Pharo forward. Just a side note: what I find cool about Pharo GUI coding is that all tools are written in Pharo. Its easy to take this for granted but taking a look at other dynamic programming languages shows that his is a blessing. I have to confess I did not understand this obsession of implementing everything in Pharo when I joined coming from python. But now I find this obsession too infectious to resist :) On Tue, Mar 24, 2015 at 11:56 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Kilon, > > The situation is like this. For quite a while we did not have enough > expertise in this community to build serious UI frameworks that can work. > In the meantime we learnt a lot. GT is not just a couple of windows. It's > an experiment of building something that does not exist anywhere else, and > we learnt a lot from doing it. For example, to make Spotter both responsive > and robust, the most difficult part was to learn to build the machinery > behind, but now we are passed that initial step. At the same time, Alain > put a ton of effort in Bloc. Athens was exercised both as the engine behind > Block and from the Roassal team. And there are others like Sean, Nicolai > and Ben who work around the same areas. > > This are all seemingly parallel and uncoordinated efforts, but they are > converging. It is exactly because we are committed to the long term goal of > building a real and better alternative to Morphic that we choose to not > stop half way with Brick which is probably enough for GT purposes and > choose instead to invest in evaluating Bloc. > > Yes, we do not have the replacement now, but we have never had so much > investment and will around the UI as we have now. We do not know at this > point what is the better way, we do not know the exact roadmap because it > is more than just a matter of implementation. But, I know that the kinds of > results we had recently around the UI is a highly encouraging predictor. > > Cheers, > Doru > > > > On Tue, Mar 24, 2015 at 5:19 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> >> " >> if you read my mail, you will notice that I said BOTH are on the table >> (and we are actually moving oon both): >> - Bloc is the redesign >> - In the mean time we WORK and ENCOURAGE others to work on improve it." >> >> Last time I asked about Bloc , I was told not to use it and instead stick >> with Spec or Morphic. >> >> I said it before and will say it again, you guys need to sit down and >> make a roadmap for Pharo because I am reading a lot of conflicting posts in >> this mailing list and this is does not give the professional look Pharo >> wants to show to people outside Pharo. As a user "replace in the long run" >> is not enough ! The original author of Bloc , Alain, also said that he is >> pretty much the only one that works on Bloc (with some help from Stef) and >> if people dont start helping him out he is going to give up. >> >> How many more threads should we have about the GUI future of Pharo before >> people really get the message that we need a roadmap ? >> >> Additionally , Pharo needs a roadmap , seriously it does. >> >> "but Morphic it self has several fundamental flaws that cannot be fixed >> and thatâs why in the long, very long way, needs to be replaced. " >> >> What flaws , where , when , how , why ? So much discussion that Morphic >> must go , close to zero discussion what the actual problems are. >> >> "First, Athens is not a replace for Morphic, is a replace for the canvas >> in which morphs are drawn. So is not Morphic or Athensâ¦ is "Morph using >> DisplayPlugin" or "Morphic using Athens". >> >> Second I did not say Athens is to replace Morphic . From my understanding >> Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am >> wrong. >> >> "Glamour is very mature and Iâve used it serval timesâ¦ and in theory >> Brick will be compatible with Glamour (mostly) so even if developers >> deprecate one for the other you will be able to use your code (mostly). " >> >> Brick is called non usable by its own authors. Glamour is framework of >> building browsers and simplified GUIs , its nowhere near as powerful as >> Morphic and is based on Morphic. From the looks of its is not even as >> powerful as Spec. Through the couple years I have been around I have seen >> at best a couple of question on how to make it work compared to hundreds of >> questions about Spec and Morphic . How something can be matured if it is >> not heavily used ? >> >> "But anyway, how can Athens be so slow? Why? Can you share some info? " >> >> You ask me to tell you why Athens is slow when we have this discussion >> before ( a few months ago) and you told me that Athens is slow because of >> how Pharo handles rendering and that as soon as we move to SDL things will >> be 10 times faster. >> >> All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for >> mercy at 50% consumption. Calling it slow , is an understatement. >> >> Other much simpler example are very slow too like the sliding logo >> example at many more. >> >> Of course this problem affects Morphic too so personally I am examining >> the possibility that no pharo library will satisfy me and instead I will >> make my own GUI API on top of QT or HTML. Obviously more work for me, >> obviously a scenario that I want to avoid, but if the alternative is an app >> that consumes 50% cpu then I dont have much of a choice. Maybe I could take >> a look at Mars too. >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Sean P. DeNigris

> I have to confess I did not understand this obsession of implementing everything in Pharo when I joined coming from python. But now I find this obsession too infectious to resist :) That's why its impossible to convert people via HN and Reddit. Like skydiving (I imagine), it seems like a really bad idea to leave the safety of ill-conceived vendor-supplied tools until you jump and actually live it for yourself for long enough to realize what freedom feels like! ----- Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814927.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Sean P. DeNigris

> Yes, we do not have the replacement now, but we have never had so much investment and will around the UI as we have now. We do not know at this point what is the better way, we do not know the exact roadmap because it is more than just a matter of implementation. But, I know that the kinds of results we had recently around the UI is a highly encouraging predictor. Well said! Things have been converging for a long time. I remember Alain showed me a Bloc ancestor at my very first ESUG. I feel that it's taken so long precisely because of our concern to preserve the awesome "build anything" power of a live, direct Morphic world while building more more mundane/standard layer(s) on top. And the results do seems to be rapidly accelerating lately. For all of us who want to participate, I think the most important first step is research. Much good thinking about this has been done at and since PARC. There are great papers, articles, and videos available about: Self Morphic, the Star user interface, VPRI's experiments with e.g. text layout, MorphicWrappers and MathMorphs, the Alternate Reality Kit to name a few. You can also play with Self and Lively Kernel to see how things are done there. I think that if we were going to replace the live, direct, uniform Morphic world with merely "a business UI toolkit" that it would have been done a long time ago! ----- Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814926.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Tudor Girba

Hi Kilon, The situation is like this. For quite a while we did not have enough expertise in this community to build serious UI frameworks that can work. In the meantime we learnt a lot. GT is not just a couple of windows. It's an experiment of building something that does not exist anywhere else, and we learnt a lot from doing it. For example, to make Spotter both responsive and robust, the most difficult part was to learn to build the machinery behind, but now we are passed that initial step. At the same time, Alain put a ton of effort in Bloc. Athens was exercised both as the engine behind Block and from the Roassal team. And there are others like Sean, Nicolai and Ben who work around the same areas. This are all seemingly parallel and uncoordinated efforts, but they are converging. It is exactly because we are committed to the long term goal of building a real and better alternative to Morphic that we choose to not stop half way with Brick which is probably enough for GT purposes and choose instead to invest in evaluating Bloc. Yes, we do not have the replacement now, but we have never had so much investment and will around the UI as we have now. We do not know at this point what is the better way, we do not know the exact roadmap because it is more than just a matter of implementation. But, I know that the kinds of results we had recently around the UI is a highly encouraging predictor. Cheers, Doru On Tue, Mar 24, 2015 at 5:19 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > " > if you read my mail, you will notice that I said BOTH are on the table > (and we are actually moving oon both): > - Bloc is the redesign > - In the mean time we WORK and ENCOURAGE others to work on improve it." > > Last time I asked about Bloc , I was told not to use it and instead stick > with Spec or Morphic. > > I said it before and will say it again, you guys need to sit down and make > a roadmap for Pharo because I am reading a lot of conflicting posts in this > mailing list and this is does not give the professional look Pharo wants to > show to people outside Pharo. As a user "replace in the long run" is not > enough ! The original author of Bloc , Alain, also said that he is pretty > much the only one that works on Bloc (with some help from Stef) and if > people dont start helping him out he is going to give up. > > How many more threads should we have about the GUI future of Pharo before > people really get the message that we need a roadmap ? > > Additionally , Pharo needs a roadmap , seriously it does. > > "but Morphic it self has several fundamental flaws that cannot be fixed > and thatâs why in the long, very long way, needs to be replaced. " > > What flaws , where , when , how , why ? So much discussion that Morphic > must go , close to zero discussion what the actual problems are. > > "First, Athens is not a replace for Morphic, is a replace for the canvas > in which morphs are drawn. So is not Morphic or Athensâ¦ is "Morph using > DisplayPlugin" or "Morphic using Athens". > > Second I did not say Athens is to replace Morphic . From my understanding > Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am > wrong. > > "Glamour is very mature and Iâve used it serval timesâ¦ and in theory Brick > will be compatible with Glamour (mostly) so even if developers deprecate > one for the other you will be able to use your code (mostly). " > > Brick is called non usable by its own authors. Glamour is framework of > building browsers and simplified GUIs , its nowhere near as powerful as > Morphic and is based on Morphic. From the looks of its is not even as > powerful as Spec. Through the couple years I have been around I have seen > at best a couple of question on how to make it work compared to hundreds of > questions about Spec and Morphic . How something can be matured if it is > not heavily used ? > > "But anyway, how can Athens be so slow? Why? Can you share some info? " > > You ask me to tell you why Athens is slow when we have this discussion > before ( a few months ago) and you told me that Athens is slow because of > how Pharo handles rendering and that as soon as we move to SDL things will > be 10 times faster. > > All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for > mercy at 50% consumption. Calling it slow , is an understatement. > > Other much simpler example are very slow too like the sliding logo example > at many more. > > Of course this problem affects Morphic too so personally I am examining > the possibility that no pharo library will satisfy me and instead I will > make my own GUI API on top of QT or HTML. Obviously more work for me, > obviously a scenario that I want to avoid, but if the alternative is an app > that consumes 50% cpu then I dont have much of a choice. Maybe I could take > a look at Mars too. > > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015