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

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

by Alain Plantec

Hello Esteban, > Most probably is because you are doing double work: you draw with Athens, but you convert it to a Form to display it (and a Form is a Morph using DisplayPlugin). > I can ensure you that if you use Athens directly with SDL2 (an example I can share with you anytime) it is orders of magnitude fasterâ¦ please share :) I would like to learn how to use SDL2. Thanks Cheers Alain > > Esteban >

March 24, 2015

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

by Thierry Goubier

2015-03-24 15:16 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 24 Mar 2015, at 14:29, kilon alios <kilon.alios(a)gmail.com> wrote: > > There is a big diffirence between Morphic and the other. Morphic is a full > solution and mature one as well. The others , with the exception of Bloc , > try to wrap things up or offering better solution to some areas. > > > The one thing I don't understand is why improving Morphic or even > redesigning it is not even on the table. Looks to me like the least painful > scenario. Unless thats the intention of Bloc to be the next generation of > Morphic. In that case I am all for Bloc. > > > 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. > > 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. > One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. Thierry

March 24, 2015

Some Memory Leak

by Sven Van Caekenberghe

Hi, There seems to be some kind of memory leak in recent Pharo 4.0 images. Image size (as saved on disk) seems to be growing very rapidly under normal use (development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to increase constantly, over a period of days. One way to look at memory use is with SpaceTally printSpaceAnalysis but that takes a while. Please help us find and fix this issue. Thanks, Sven

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Alain Plantec

Hello Sean, As Iâve already said, Iâm currently working on a documentation on Bloc. Iâve stopped adding new things into it (well only examples and bug fixes) It is far from being finished and polished https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc <https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc> have a look at BlocCore.pillar please, be patient, I canât work full time on it, unfortunately Cheers Alain > Le 24 mars 2015 Ã 14:41, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > Tudor Girba-2 wrote >> Concretely, on March 31 and April 1 (no joke :)), we have a session in >> Bern >> where Alain Plantec will join us to look into how to approach this problem >> concretely. > > Given that, now I /really/ feel it would be beneficial to have the talks > recorded because otherwise you increase your work exponentially by excluding > the bulk of the community from the conversation. You will have to try and > convey all the decisions and rationales over what... the lists? AFAICT many > Morphic replacements have failed primarily due to lack of community buy in. > Let's finally break that trend! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.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 Esteban Lorenzano

> On 24 Mar 2015, at 14:29, kilon alios <kilon.alios(a)gmail.com> wrote: > > There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. > > The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. 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. 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. > > I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc. 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). > > The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too. 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". But anyway, how can Athens be so slow? Why? Can you share some info? Most probably is because you are doing double work: you draw with Athens, but you convert it to a Form to display it (and a Form is a Morph using DisplayPlugin). I can ensure you that if you use Athens directly with SDL2 (an example I can share with you anytime) it is orders of magnitude fasterâ¦ Esteban > > On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > And wellâ¦ I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: > > - we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) > - we have Spec to support our tooling. > - we have Glamour to supportâ¦ well, our tooling too. > - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. > GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). > GTTools team has also stated they would use Bloc is they could/when they can. > - We have the old Text Editor > - We have Rubric, which was stated to be âold stuffâ and deprecated > - We have also the new TxModel which intends to replace both, Text Editor and Rubricâ¦ but it cannot be used right now (or better: It cannot replace none of the previous yet) > > Soâ¦ which one to use? > We, the board, have something clear and some other not so clear yet, for example: > > - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) > - Spec needs work too > - Glamour will be replaced by Brick, so do not use it > - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. > > So wellâ¦ yes this is a mess. Yes we are aware. No we donât know when things will improve, but *they will*. > In the mean time as a Pharo user, I would like to know which one should I use for my projectsâ¦ this is my recommendation: > > - Do not use âdirectâ Morphic unless doing graphics > - Use TxModel and if you cannot, Rubric > - Use Brick or Spec, not Glamour (because Brick will replace it soon) > > And of course, I would help with fixes and reports on everything :) > > > cheers, > Esteban > > > > >> On 24 Mar 2015, at 12:37, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi Nicolai, >> >> I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :) >> >> Let's recap. >> >> Brick was created to support GT. We wanted GT in the image, hence Brick is in the image as part of Glamour. In the meantime, Brick has grown and it's now an almost standalone framework, but it is not yet advisable to use it apps because it will likely change more. >> >> As Alex says, we do not want to have two competing new projects running in parallel (Brick and Bloc) and fragmenting the effort even more. That is why, for Pharo 5 we want to invest in Bloc. The interesting thing is that while Bloc starts from scratch, Brick already works and has quite some high level widgets and logic built in. Brick is already going in the same direction expected by Bloc, so we will likely have the opportunity of moving Brick on top of Bloc (Alex already did an experiment in this direction). >> >> Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern where Alain Plantec will join us to look into how to approach this problem concretely. >> >> All in all, you should see Brick as a pragmatic intermediary step towards removing Morph. I agree that it can be better (what cannot be), but I disagree we should discard GT because of it. >> >> Cheers, >> Doru >> >> >> On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>>: >> Hi, >> >> Sorry if my reply will be too long, but I tried to summarise our experience with Morphic/Brick and give some useful feedback or even provide ideas. Who wants will read :) >> >> Hi, >> thank you, this is a really great source of information, and it would be heplful >> to have this kind of write up somewhere else (not in the mailinglist). >> But I did not question why we may need brick or why it is done. >> My question was, what are the feature plans, is it just an experiment that >> can vanish, so it is better to not use it for the core tools. Or is it meant to be >> THE new framework we should gain our focus on. >> >> >> Brick is not a thin layer anymore. >> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born out of need. Spotter is completely built using Brick and Rubric. >> >> This is something I don't understand. As we integrated GT-Tools into the image, Rubric >> slipped in as it is need by GT. I asked what is the background, what are the feature plans >> and complained about the undocumented core classes, that makes it difficult to see >> what changed compared to the old text classes. Alain said he doesn't plan to do further >> work on Rubric. >> So, WHY don't we replace and migrate the existing classes now and clean it up. It takes so >> much resources to maintain both. Every theme change, every change on shortcuts/menus/keymapping, the athens drawing, all has to be double checked - It is so exhausting. >> >> >> No morphs are used at all (except Rubric of course). >> >> Well, all Bricks ARE morphs, they share the same state and api. >> >> All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. >> >> If so, the clean/better way would be to extract those part into a "ProtoMorph" or a "PlainMorph". >> and subclass from that once for Brick and again for Morphs. >> Now we have Bricks, that are looking like a Morph, but aren't used to be one, and probable doesn't even work if they are used as Morphs. >> (Sure this is true for other Morphsubclasses as well, but that does not means it doesn't hurt if we do more of this). >> >> Everything else was rewritten from scratch. During some period of time Brick was able to render itself on Athens canvas, but we dropped it because of Font issues in athens. >> There are even more issues for Athens, and they don't vanish magically. There are some issues >> on fogbugz just waiting for some feedback, preferable from people intending to use Athens. >> >> Spotter is not the only tool written using Brick, GLMPager - a pane pager in GT-Inspector, GT-Playground and GT-Debugger is also completely done using Brick. Almost all tab labels and tab selector in GT tools are Bricks. >> >> >> ... >> >> >> We really would like to move all tools to Bloc as soon as possible, but we just need something right now that works and can be used in current version. >> >> But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is needed to push >> this into the release. >> >> I think we will never (but who knows) announce Brick as separate project. In our minds it is just useful helper library. >> >> For me, this just disqualifies Brick from being used in the core image. >> >> >> I see that many things in the GToolkit are better than the old one (theming/layouting/delegate behavior in sub(classes/bricks). Great, it makes fun to work with it,extending the inspector or Spotter search. >> >> But I don't understand why this is pushed that way and on top of the old system/classes instead of cleaning that up. >> >> >> nicolai >> >> >> Thanks for reading :) >> >> Cheers, >> Alex >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > >

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Tudor Girba

There is only one talk about Bloc. The rest is like a sprint. Doru On Tue, Mar 24, 2015 at 2:41 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > Concretely, on March 31 and April 1 (no joke :)), we have a session in > > Bern > > where Alain Plantec will join us to look into how to approach this > problem > > concretely. > > Given that, now I /really/ feel it would be beneficial to have the talks > recorded because otherwise you increase your work exponentially by > excluding > the bulk of the community from the conversation. You will have to try and > convey all the decisions and rationales over what... the lists? AFAICT many > Morphic replacements have failed primarily due to lack of community buy in. > Let's finally break that trend! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Sean P. DeNigris

Tudor Girba-2 wrote > Concretely, on March 31 and April 1 (no joke :)), we have a session in > Bern > where Alain Plantec will join us to look into how to approach this problem > concretely. Given that, now I /really/ feel it would be beneficial to have the talks recorded because otherwise you increase your work exponentially by excluding the bulk of the community from the conversation. You will have to try and convey all the decisions and rationales over what... the lists? AFAICT many Morphic replacements have failed primarily due to lack of community buy in. Let's finally break that trend! ----- Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.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 kilon alios

There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc. The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too. On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > And wellâ¦ I think Nicolai is right in a point (not the fault of Brick, > btw): current status is far from ideal: > > - we have Morphic, and itâs upcoming replace, Brick (but Brick is not in > the image, so the pain there is less) > - we have Spec to support our tooling. > - we have Glamour to supportâ¦ well, our tooling too. > - we have now Brick, who (AFAIS) is an extension of Morphic, and a > replacement the Morphic Widgets and also Glamour. > GTTools team has explicitly declared Brick will replace Glamour (but API > will remain largely compatible, they say). > GTTools team has also stated they would use Bloc is they could/when they > can. > - We have the old Text Editor > - We have Rubric, which was stated to be âold stuffâ and deprecated > - We have also the new TxModel which intends to replace both, Text Editor > and Rubricâ¦ but it cannot be used right now (or better: It cannot replace > none of the previous yet) > > Soâ¦ which one to use? > We, the board, have something clear and some other not so clear yet, for > example: > > - we would like to replace Morphic with Bloc, but this is a lot of work > and will take a lot of time so in the mean time we also clean old Morphic > as much as we can (and we encourage people to do it) > - Spec needs work too > - Glamour will be replaced by Brick, so do not use it > - TxModel will replace all the previous, but it needs a lor of work. In > the mean time, we suggest to use and improve Rubric, and of course, we > would like to have more people contributing to TxModel. > > So wellâ¦ yes this is a mess. Yes we are aware. No we donât know when > things will improve, but *they will*. > In the mean time as a Pharo user, I would like to know which one should I > use for my projectsâ¦ this is my recommendation: > > - Do not use âdirectâ Morphic unless doing graphics > - Use TxModel and if you cannot, Rubric > - Use Brick or Spec, not Glamour (because Brick will replace it soon) > > And of course, I would help with fixes and reports on everything :) > > > cheers, > Esteban > > > > > On 24 Mar 2015, at 12:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Nicolai, > > I am surprised by your conclusion that the current Brick implementation > disqualifies it from being part of the Core :) > > Let's recap. > > Brick was created to support GT. We wanted GT in the image, hence Brick is > in the image as part of Glamour. In the meantime, Brick has grown and it's > now an almost standalone framework, but it is not yet advisable to use it > apps because it will likely change more. > > As Alex says, we do not want to have two competing new projects running in > parallel (Brick and Bloc) and fragmenting the effort even more. That is > why, for Pharo 5 we want to invest in Bloc. The interesting thing is that > while Bloc starts from scratch, Brick already works and has quite some high > level widgets and logic built in. Brick is already going in the same > direction expected by Bloc, so we will likely have the opportunity of > moving Brick on top of Bloc (Alex already did an experiment in this > direction). > > Concretely, on March 31 and April 1 (no joke :)), we have a session in > Bern where Alain Plantec will join us to look into how to approach this > problem concretely. > > All in all, you should see Brick as a pragmatic intermediary step towards > removing Morph. I agree that it can be better (what cannot be), but I > disagree we should discard GT because of it. > > Cheers, > Doru > > > On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> >>> Hi, >>> >>> Sorry if my reply will be too long, but I tried to summarise our >>> experience with Morphic/Brick and give some useful feedback or even provide >>> ideas. Who wants will read :) >>> >> >> Hi, >> thank you, this is a really great source of information, and it would be >> heplful >> to have this kind of write up somewhere else (not in the mailinglist). >> But I did not question why we may need brick or why it is done. >> My question was, what are the feature plans, is it just an experiment that >> can vanish, so it is better to not use it for the core tools. Or is it >> meant to be >> THE new framework we should gain our focus on. >> >> >>> >>> Brick is not a thin layer anymore. >>> >>> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was >>> born out of need. Spotter is completely built using Brick and Rubric. >>> >> >> This is something I don't understand. As we integrated GT-Tools into the >> image, Rubric >> slipped in as it is need by GT. I asked what is the background, what are >> the feature plans >> and complained about the undocumented core classes, that makes it >> difficult to see >> what changed compared to the old text classes. Alain said he doesn't plan >> to do further >> work on Rubric. >> So, WHY don't we replace and migrate the existing classes now and clean >> it up. It takes so >> much resources to maintain both. Every theme change, every change on >> shortcuts/menus/keymapping, the athens drawing, all has to be double >> checked - It is so exhausting. >> >> >> >>> No morphs are used at all (except Rubric of course). >>> >> >> Well, all Bricks ARE morphs, they share the same state and api. >> >> >>> All Bricks in Spotter in the end are subclasses of GLMBrick, which uses >>> from original Morph only Canvas (without drawing) and MorphicEvents. >>> >> >> If so, the clean/better way would be to extract those part into a >> "ProtoMorph" or a "PlainMorph". >> and subclass from that once for Brick and again for Morphs. >> Now we have Bricks, that are looking like a Morph, but aren't used to be >> one, and probable doesn't even work if they are used as Morphs. >> (Sure this is true for other Morphsubclasses as well, but that does not >> means it doesn't hurt if we do more of this). >> >> >>> Everything else was rewritten from scratch. During some period of time >>> Brick was able to render itself on Athens canvas, but we dropped it because >>> of Font issues in athens. >>> >> There are even more issues for Athens, and they don't vanish magically. >> There are some issues >> on fogbugz just waiting for some feedback, preferable from people >> intending to use Athens. >> >> >>> Spotter is not the only tool written using Brick, GLMPager - a pane >>> pager in GT-Inspector, GT-Playground and GT-Debugger is also completely >>> done using Brick. Almost all tab labels and tab selector in GT tools are >>> Bricks. >>> >>> >> ... >> >> >>> >>> We really would like to move all tools to Bloc as soon as possible, but >>> we just need something right now that works and can be used in current >>> version. >>> >> >> But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it >> is needed to push >> this into the release. >> >> >>> I think we will never (but who knows) announce Brick as separate >>> project. In our minds it is just useful helper library. >>> >> >> For me, this just disqualifies Brick from being used in the core image. >> >> >> I see that many things in the GToolkit are better than the old one >> (theming/layouting/delegate behavior in sub(classes/bricks). Great, it >> makes fun to work with it,extending the inspector or Spotter search. >> >> But I don't understand why this is pushed that way and on top of the old >> system/classes instead of cleaning that up. >> >> >> nicolai >> >> >>> >>> Thanks for reading :) >>> >>> Cheers, >>> Alex >>> >> >> > > > -- > 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 Esteban Lorenzano

> On 24 Mar 2015, at 14:23, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Esteban, > > 2015-03-24 13:56 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > And wellâ¦ I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: > > - we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) > > I suspect you mean Bloc, not Brick there, no? Now I'm lost ;) oops! yes, Bloc :P > > Thierry

March 24, 2015

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

by Thierry Goubier

Hi Esteban, 2015-03-24 13:56 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > And well... I think Nicolai is right in a point (not the fault of Brick, > btw): current status is far from ideal: > > - we have Morphic, and it's upcoming replace, Brick (but Brick is not in > the image, so the pain there is less) > I suspect you mean Bloc, not Brick there, no? Now I'm lost ;) Thierry

March 24, 2015