August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About better communication in the community

by Denis Kudriashov

In context of discussion how to propose Mocketry and StateSpecs to be part of Pharo? We often said that Pharo provides the best approach to TDD but we have no mock library inside. And nobody use mocks for Pharo tests because of that 2016-08-24 6:51 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > the board got a good discussion at ESUG about how to improve and a lot of > the discussion turned around improving communication. We got some ideas > that we will propose soon but I would like to get *your* ideas. > > If you have idea about improving communication around pharo please tell us. > > > Stef > > >

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by Denis Kudriashov

2016-08-24 9:38 GMT+02:00 stepharo <stepharo(a)free.fr>: > Igor looked at Twisty seriously and I do not think that it could handle > large cobol files. > > (you see funnily denis is doing the same with Seamless - He rewrote it > from scratch while > nick worked on it for several years). > Just to clarify: Twisty was not rewrite of TxText. When Igor returned to project I already moved to my design ideas which was opposite to Igor. And I just decided to finish what I started with new project name. About long files - TxText optimization needs to be implemented in Twisty. That's all. Current design could be evolved for it. I does not know which project is better. In Twisty I implemented my practical needs: various kinds of editors. To approve which design is better someone needs to implement same in TxText and compare it with Twisty. Probably simple example of masked text could be enough. And I must mention Seamless to clarify that Nick work is not lost. He implemented important ideas on asynchronous data transfer which helps me a lot. I extracted them to separate project Basys with better abstraction which is independent from Seamless goals. It improved testability and leaded to rest of other changes.

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by Denis Kudriashov

Hi 2016-08-24 18:58 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 2. Features that goes inside Pharo are not decided by vote. They have to >> add value and share the Pharo vision (pointed in the vision document who is >> not slightly updated but still guides our steps). We try to reach consensus >> and if it is not possible, then we decide. Yes, is like thatâ¦ Iâm sorry for >> not being perfect democratic but this was never the idea of Pharo (it *has* >> a benevolent dictatorâ¦ who by the way is not me but a group, the board). >> >> > Ok, now people can see one reason why Pharo is light years from the > popularity of other OSS. I don't get how do you expect success with Pharo > if you never change your mindset... I read a lot of papers and see KDE, > gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never > *ever* read something like that, specially now where OSS literature is > considering distributed democracy. > I would say Pharo is still too young. And Pharo parents want to bring up it in own way. I think at some point Pharo could become adult enough to move away from parents (in good meaning of these words:) (without losing respect to parents vision)).

Aug. 27, 2016

Re: [Pharo-dev] MorphicDoc?

by Dimitris Chloupis

Yeah my bad it would suppose to be a documentation project for Morphic. There should be some content though. But since we move to Bloc I will delete it. On Sat, 27 Aug 2016 at 12:11, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Anyone knows what is MorphicDoc (Kilon?) > I loaded the stable configuration in Pharo 5.0, but I can not find any > content. > > (missing dependencies / packagese maybe ? ) >

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by stepharo

Hi yuriy A package manifest is the place where we keep package rules and meta data. We should add documentation and others. I think that all the packages should have a XXXManifest. There we can define a method preUnload and after we can define a class PackageUnloader (or put the logic in the PackageOrganiser way better :)). So that we can say PackageOrganiser current unload: 'XXX' and the preUnload is executed. Stef Le 27/8/16 Ã 16:23, Yuriy Tymchuk a Ã©crit : >> On 27 Aug 2016, at 11:00, stepharo <stepharo(a)free.fr> wrote: >> >> You see hernan doing positively is the best way to make that things happen >> >> We can have a >> >> preUnload hook >> >> Now we should check how it fits with cleanForProduction and others. >> >> But we should definitively have a way to express this. >> >> So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks >> >> and if you really want to get a better Pharo for you then talk to them and us. >> >> >> https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA > I like the idea, but how should it work? What is the package manifest? And how the unload protocol looks like? Do I only add a method called #unload to somewhere? > > Uko > >> https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-S… >> >> https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-G… >> >> https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT >> >> Stef >> > >

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by Yuriy Tymchuk

> On 27 Aug 2016, at 11:00, stepharo <stepharo(a)free.fr> wrote: > > You see hernan doing positively is the best way to make that things happen > > We can have a > > preUnload hook > > Now we should check how it fits with cleanForProduction and others. > > But we should definitively have a way to express this. > > So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks > > and if you really want to get a better Pharo for you then talk to them and us. > > > https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA I like the idea, but how should it work? What is the package manifest? And how the unload protocol looks like? Do I only add a method called #unload to somewhere? Uko > > https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-S… > > https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-G… > > https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT > > Stef >

Aug. 27, 2016

Confused by remote logic ;)

by stepharo

KomitNewSlice>>remote ^ MCRepositoryGroup default repositories detect: [ :e | e description = 'http://smalltalkhub.com/mc/Pharo/Pharo50Inbox/main/' ] ifNone: [ MCRepositoryGroup default repositories detect: [ :e | e description = 'http://smalltalkhub.com/mc/Pharo/Pharo50Inbox/main' ] ] may be the first time one is magically created :) Stef

Aug. 27, 2016

Polymorphic results would be good

by stepharo

Hi I'm cleaning Smalltalk ui icons usage again and more :) I just want to share with you. I see code like that KomitDirectoryRemote>>icon ^ 'DIR' KomitGemstoneRemote>> icon ^ Smalltalk ui icons iconNamed: #komitterGemstoneRemote It would be nice if we could be cleaner and makes sure that we do not return totally different objects. Stef PS: Some of you can understand why I was not found of Komitter and suggested to remove it. So let us improve it.

Aug. 27, 2016

Re: [Pharo-dev] About Pharo 60

by Esteban Lorenzano

> On 27 Aug 2016, at 14:40, stepharo <stepharo(a)free.fr> wrote: > > Hi esteban > > I think that we should identify the main hook points and slowly prepare them. > > The system should be prepared for that so that we just need to pass a context to configure it. .. I should have that old package somewhereâ¦ it will not work, and it was not very subtleâ¦ but it has to be somewhere :) Esteban > > Stef > > > Le 27/8/16 Ã 14:32, Esteban Lorenzano a Ã©crit : >> yes, some years ago I made a package for this. >> later Ben tried something similar with the user manager. >> none of those approaches worked as general approach because you need to âcloseâ a lot of thingsâ¦ (not just the spotterâ¦ which by the way, NEEDS to have a setting, no idea who answered you that but he is wrong), and image is not prepared for that. >> >> of course is still possible :) >> >> anyway, today I would tackle a solution in a different way: I would open my app morph on an SDL2 window and not touch the word at all (opening a headless image). This is not possible in windows because when you do âheadlessâ it just laugh at you, but is doable in the not-so-long term. >> >> Esteban >> >>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >>> >>> Le 27/08/2016 Ã 13:18, stepharo a Ã©crit : >>>> >>>> YES!!! >>>> >>>> Do you know how Settings works? >>>> We can adapt it this way. >>> When I improved the deployment of Synectique Tools I asked to get a >>> simple way to disable Spotter via a setting but I got as answer "No >>> because you can do it by removing a global shortcut so it is not needed.". >>> >>> People in companies don't have the time to learn how shortcuts work and >>> how to remove one without impacting something else. And they don't have >>> the time to check Spotter code to know how it is call. >>> >>> If the image is able to have a deployment mode then I don't care how >>> Spotter is disabled (setting or removing a shortcut). But for now we >>> don't have it. :) >>> >>>> I mean the User approach that Benjmain proposed and was pushed in Pharo >>>> was not good because it was not modular. Now each part of the system >>>> should be >>>> defined in way that it can be set just as a setting. >>>> We should not have >>>> >>>> World .... >>>> User current = ifTrue >>>> >>>> But >>>> >>>> World use: userSetting >>>> >>>> and World should handle it. >>>> There is way more to do :) >>>> When you deploy on linux you should be able to say beSilent to the >>>> system (do not write on places that you cannot). >>>> Valentin works on it and we should continue >>>> >>>> Stef >>>> >>> The fact that there is much more to do is the main reason for Pharo to >>> do it and not the developer. The developer cannot know all the system >>> and will not be able to protect the code of his company well because he >>> will forget something as to disable ctrl+o+p (or he is a god developer! >>> But everyone is not). >>> >>> This is a large thing to do, so it would be cool that everyone keep that >>> in mind to allow it little by little (as with the work of Valentin). >>> >>> -- >>> Cyril Ferlicot >>> >>> http://www.synectique.eu >>> >>> 165 Avenue Bretagne >>> Lille 59000 France >>> >> >> > >

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by stepharo

So I think that I will keep Eyeinspector for Spec because it works well using Spec. I will package BasicInspector Then we will see. I think that Smalltalk tools inspector is not good because it is yet another global while the tools should have a tool context (but with a registration mechanism to get refreshed in case). Stef Le 27/8/16 Ã 10:51, stepharo a Ã©crit : > I took the inspector from Pharo20 and I will check if it is working in > Pharo. > Then I will > - check EyeInspector from a package perspective (extensions and > the rest) > - make sure that we can remove EyeInspector > - package the attached file as BasicInspector. > > Now if you want to help you are welcome. > > Stef

Aug. 27, 2016