I would like also to see what is the vision for the future of Moose. Because we will put some effort on the table but not blindly and I would like to avoid to throw away months of work. I would like to know what is the status of Glamour development because iceberg shows that Glamour is buggy. We also have memory leaks in Pharo because of GT tools and this is super annoying. I think that there are too many announcers to my personal taste stef -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Hi doru Yes I suggest that we plan multiple talks because one will not be enough. We should also present what we will do around Spec2 but first we should have a prototype because it will clean a lot of mess and works with Morphic and Bloc. You will tell me what you mean because this is not clear. I do not see for now the difference. With git I thought that you can reload a version and dependent components held in the same repository based on a hash. We do not need to handle the versions as with MC but I think that this only works for components stored in the same repo. This is why we should really think about what is Moose. I will ask the experts around. Discuss with esteban. Because we should do something. Ok this is good to know. Because Moose++ should not rely on Glamour then and it means that RMOD will not invest there. I suspected it so good to know. We think that except GTTool, Pharo should not depend on Glamour so that we can unload it. So we will check and redo all the tools that are not GT to not use Glamour. Now there are two problems that I would like to see changed in the future - no comment at all in methods. This is the last time that I accept components in Pharo in that state Same apply for Spec and other BTW - Subclasses when superclass could have been improved. For example GLMAnnouncer methods should not be there but most of them should have been put the superclass. This is not the way to grow a strong infrastructure. - Having all the classes subclasses of Announcer looks like a bad design strategy. I have large concerns about the engineering behind GT widgets and Glamour and overall super complex design of GT in general. I can understand that you want generic solution but generic solutions have a cost. Now I sincerly hope that the new version will be less complex because Pharo needs simplicity and often you discarded this argument but this argument is real and it can kill us. We cannot for example spent days looking for memory leaks. Now you see something that is symptomatic to me: let us look at Beacon / SystemLogger. I do not care about SystemLogger. Now I worked on it (and the design could be better). Then you came with Beacon which basically killed SystemLogger. Then nothing. We still have this fucking Transcript everywhere and not object transcript. There were not a single effort to build the next step. While I was planning to do it with SystemLogger. You killed my energy and all the effort around. And you produce Beacon and two people are using it. So I will check with the guys here what they think about Beacon and may be do a pass on SystemLogger or another iteration. Now for me the main problem (and there is a pattern with Glamour here) is that I do not know how to maintain Beacon while I know how to maintain SystemLogger (it is limited and simple and not super generic and super powerful but I can maintain it). The same happens with Glamour. Probably the same happens with Spotter. If esteban cannot fix easily Glamour (Iceberg suffered A LOT of bugs in Glamour like the refresh to index in list) then there is an ENGINEERING problem. Now we can discard this argument. The point is still there. So at the end I want to say that I may prefer that Pharo does not have hyperfancy features that only two people master and that we (the guy spending time on cleaning) can manage our system. The point is that we should take care of modularity and I would like to avoid to be also forced to pay attention for others. We will have to check this because even for Pharo we want to avoid to have the Glamour/Annoucement hell around when you will consider that another project is more important. Yes but not only. You see when we introduced Glamour in Pharo. You remember I was against it and you said that it was only 35 classes and that I could maintain Morphic that was far more complex. Net result. ***We*** were fighting multiple time with memory leaks. The design is overly complex. What we introduce in Pharo should be maintainable by the majority. - method comments (look at Glamour not a single method comment!!!!!!!!!) - decent class comments and not just plain shit “this class is abstract” - tests and not with a super funky system that only one guy understand - less use of Pragmas - You see if I use Statespecs and you use GTExample and denis use his testing framework because it is cooler then when we improve SUnit (which we will do) then fewer components benefit from it we have to pay attention to Statespecs, GTExample,….. instead of ONE framework. I think that Pharo will get a lot more picky about its components. So We are talking about Pharo 8.0 so you can be prepared. But do not come to tell me that we did not tell it. I really think that Pharo 8.0 will be about massive cleaning up. So as a community we will have to have a real discussion about Pharo 80 because we will raise the bar and I will push all my voice for that because we cannot continue like that. I think that we should set some basic rules such as the tools we want for Pharo development and the quality rules. Stef -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

May be we could add you to the discussion we have via discord. ahh. Now I think that we will face problems in Pharo :) -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Ok -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Hi, Sounds great. I love these discussions, btw. I think they are very healthy especially when they lead to actions. It’s easy to get lost in day to day work and have things that get "lost in translation”. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."