January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Blame support P7

by Stephan Eggermont

Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Stephan, > Then why on /earth/ would one stop using Smalltalk in /the most central > part/ of the collaborative programming process, version control? Because of the underestimation of the work needed, vs. the advantage of eliminating one barrier to entry. One of the differences in perspective is that Stef sees lots of people new to smalltalk (students) and needs them to get up to speed really fast. The collaboration needs there are different from yours, where you need to deal with long-term collaboration mostly between experts. There is also a significant underestimation of the complexity of version control, and the need to support different workflows. The community members having experience managing complex workflows don't manage to explain well enough what they need. Stephan

Jan. 13, 2018

Re: [Pharo-dev] [Pharo-users] Pharo Lecture at Tunis next week

by Tudor Girba

Thanks a lot for the effort of promoting and spreading Pharo! Doru > On Jan 13, 2018, at 1:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > just to tell you that next week I will give a lecture at ENIS at tunis. > 3 full days of Pharo and advanced design. > > Stef > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Jan. 13, 2018

Re: [Pharo-dev] Protocol names convention

by Norbert Hartl

> Am 13.01.2018 um 13:37 schrieb Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Eliot, > > On 13 January 2018 at 12:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> And it would be nice to have tool support to suggest protocol names to maintain consistency so that the same selector usually appears in the same protocol. Spelling rorres are intivetible and should be fixed when found. > > This is partly already available. If you select the '-- all --' > category, enter and save a method, the browser will guess which > protocol to put the method in. If the method is implemented by a > superclass it will be put in the same protocol, so #initialize will be > put in to 'initialization' (where it is in ProtoObject). > > Cheers, > Alistair Sounds great! In which class is the code that does the decision about the right name? I think I find my convention here.+ Norbert

Jan. 13, 2018

Re: [Pharo-dev] Protocol names convention

by Alistair Grant

Hi Eliot, On 13 January 2018 at 12:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > And it would be nice to have tool support to suggest protocol names to maintain consistency so that the same selector usually appears in the same protocol. Spelling rorres are intivetible and should be fixed when found. This is partly already available. If you select the '-- all --' category, enter and save a method, the browser will guess which protocol to put the method in. If the method is implemented by a superclass it will be put in the same protocol, so #initialize will be put in to 'initialization' (where it is in ProtoObject). Cheers, Alistair

Jan. 13, 2018

Pharo Lecture at Tunis next week

by Stephane Ducasse

Hi guys just to tell you that next week I will give a lecture at ENIS at tunis. 3 full days of Pharo and advanced design. Stef

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Norbert Hartl

> Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Stephan, > > >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> Isn't it important to preserve the ability to exchange code >> between Pharo, >>> Squeak and Cuis? Don't you care that the VM development is directly >>> affected by this? Is the VM and plugin support not important to Pharo? >> >> Git support turns out to be much more work than we hoped and expected. Too >> many library updates needed, support for different workflows and platforms, >> switch to file per class. The Iceberg channel on Discord is one of the >> busiest channels. > > You don't say? One of ClÃ©ment's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk. We are hugely productive in the vm simulator. People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal. > > Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control? This is a huge blunder. Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities. Iceberg is well named. People rearranged the chairs on deck while the Titanic sank. > Can we agree that a class/method/â¦ stops being smalltalk after it has been serialized to text? If you can agree to this I donât know what you are talking about. We exchange the to-text-serializer monticello-backend with git-backend. The rest (the important part) stays nearly the same. The exchange is necessary because the possibilities of collaboration are limited when using monticello only. So what would be the alternative? There are even a lot of people that donât like git (including me). But I like the collaboration model because that can do what no smalltalk tool can do to my knowledge. Or to turn your argument around. You are a small vm team and you have to be small because I doubt with the current collaboration model you are able to grow. Norbert >> >> Stepha > > _,,,^..^,,,_ (phone)

Jan. 13, 2018

Re: [Pharo-dev] Protocol names convention

by Eliot Miranda

Hi Norbert, > On Jan 13, 2018, at 3:32 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Iâm not the biggest fan of method categories/protocols but I try to. > What strikes me is the huge mess in names we have. Everytime I create e.g. an initialize method Iâm asking myself which is the proper name to choose > > initialize > initializing > initialization > â¦. > > Do we have a convention for this? > > Right now all names starting with init are > > initialization-data > initialize-destroy > initialization-filter > initialize - release > initialize > initialization-union > initialize - event > initializing > initialization > initalize-release > initailize-release > initialization widgets > initalize > initialize-release > initialization-release Funny. Your list (of course) omits one of the best: instance initialization In the original Smalltalk-80 the one used was initialize-release because the system, having a reference counting garbage collector, needed explicit cycle breaking for garbage to be reclaimed and so there were some important release methods in the compiler and the GUI. But these became obsolete when scavenging was introduced, and so in the parcplace code instance initialization started replacing initialize-release. I think protocol names should use the passive voice since the active voice suggests specific usage. So initialization is better than initialize et al. And it would be nice to have tool support to suggest protocol names to maintain consistency so that the same selector usually appears in the same protocol. Spelling rorres are intivetible and should be fixed when found. > Norbert >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Andreas Wacknitz

Am 13.01.18 um 12:39 schrieb Eliot Miranda: > Hi Stephan, > > >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> Isn't it important to preserve the ability to exchange code >> between Pharo, >>> Squeak and Cuis? Don't you care that the VM development is directly >>> affected by this? Is the VM and plugin support not important to Pharo? >> Git support turns out to be much more work than we hoped and expected. Too >> many library updates needed, support for different workflows and platforms, >> switch to file per class. The Iceberg channel on Discord is one of the >> busiest channels. > You don't say? One of ClÃ©ment's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk. We are hugely productive in the vm simulator. People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal. > > Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control? This is a huge blunder. Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities. Iceberg is well named. People rearranged the chairs on deck while the Titanic sank. +1

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> Isn't it important to preserve the ability to exchange code > between Pharo, >> Squeak and Cuis? Don't you care that the VM development is directly >> affected by this? Is the VM and plugin support not important to Pharo? > > Git support turns out to be much more work than we hoped and expected. Too > many library updates needed, support for different workflows and platforms, > switch to file per class. The Iceberg channel on Discord is one of the > busiest channels. https://en.m.wikipedia.org/wiki/Error_33 > > Stephan > >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

Hi Stephan, > On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> Isn't it important to preserve the ability to exchange code > between Pharo, >> Squeak and Cuis? Don't you care that the VM development is directly >> affected by this? Is the VM and plugin support not important to Pharo? > > Git support turns out to be much more work than we hoped and expected. Too > many library updates needed, support for different workflows and platforms, > switch to file per class. The Iceberg channel on Discord is one of the > busiest channels. You don't say? One of ClÃ©ment's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk. We are hugely productive in the vm simulator. People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal. Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control? This is a huge blunder. Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities. Iceberg is well named. People rearranged the chairs on deck while the Titanic sank. > > Stephan _,,,^..^,,,_ (phone)

Jan. 13, 2018