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

Re: [Pharo-dev] Protocol names convention

by Stephane Ducasse

Bingo :) I fixed the automatic categoriser and refrain myself from fixing all the deprecancies. Stef On Sat, Jan 13, 2018 at 1:37 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > 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

Re: [Pharo-dev] Protocol names convention

by Stephane Ducasse

Norbert I developed a tool to analysis the use of protocol and fix them. It can show you the distribution and the problems. You can load it: AutomaticMethodCategorizer. Now I call my protocol initialization because initialize-release is dated :) Stef On Sat, Jan 13, 2018 at 12:32 PM, 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 > > Norbert >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

Hi StÃ©phane, > On Jan 13, 2018, at 5:00 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi eliot > > Why do you attack me personally on this? I am /not/ attacking you personally. I am criticizing the architecture. It is complex and fragile and it is already affecting the vm. > I paid with my team money the salary of clement to work with you and I > never said a word on the direction. > So I would appreciate that you respect me. Thanks in advance for your > understanding. What are you talking about? I have spent my own personal money on this collaboration also. What does my having spent money here have anything that bro with it? Are you saying that the Pharo community have got no benefit from the vm? > > Personally I would like to have a Pharo VM that does not crash when I > type because of keybinding and freetype. > And many more usability concerns. That is not my fault. You paid John McIntosh to write the iOS code. And that's where the bug lies. It is not my responsibility that fix it. > > I will not reply to this thread anymore because I do not like to be insulted. I am not insulting you. Stop taking things personally and address the subject, which is Monticello/got integration and not your feelings. Grow up and lead your community. Stop acting like a child. You persistently take things personally and it makes having a technical discussion very very difficult. Not to mention trying to mend relationships as I've tried between you and Right Bert Hirschfeld and others who find your petulance unacceptable. Monticello/git integration is a very very important topic. The same chess ofvyhr Pharo project hinges on it bring done right. That means subjective by it to criticism. If you want this to succeed you will separate your personal final feelings from the topic and bring my your considerable intelligence to bear on the subject. > Stef > > > >> On Sat, Jan 13, 2018 at 5:22 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Stephane, >> >> On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Hi torsten >>> >>> we have a super long list of *important* fixes and enhancements to do. >> >> >> 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? >> >>> >>> >>> Stef >>> >>>> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> Not having timestamps/authors in Pharo 7 due to git and missing blame >>>> support >>>> (see [1]) has other bad side effects: >>>> >>>> >>>> - it clobbers all method stamps in an MCZ package [1] if you use >>>> Monticello >>>> which can lead easily to trouble/lamenting >>>> >>>> - it is not possible to fileout a changeset [2] in the ChangeSorter >>>> >>>> Was there any further discussion/decision for P7 on solving this >>>> or adding blame support? >>>> >>>> Thx >>>> T. >>>> >>>> >>>> [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html >>>> [2] >>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html >>>> [3] https://pharo.fogbugz.com/f/cases/20951/ >>>> >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Stephane Ducasse

I think that some people are talking without really understanding. Let me shed some light - Iceberg uses the Monticello meta model to compute models and store information in Git (files). - Now Monticello just stores the information in zip files. - In addition Pharo itself is doing the diff model and does not let git doing the diff between models. So I do not understand why Iceberg is less Smalltalk centric than Envy or Store (BTW about store I would have a lot to say about the industrial strength of the product - one db expert look at the model and he was realllllllly surprised.). - Now what Git gives us is that we can manage C, Pharo, PNG, css, .... the same way. In addition you may not like git (I do not like git personally but I really love the model) and we need to have a real decentralized source versioning control system. We are not afraid by sharing :) and collaborating. The world is using Git and we are too. The situation will improve and it will continue to improve. Now it looks like the great smalltalk community does not like when people get some traction. I cannot do much for them. Do not participate, complain and tell us that we are plain idiots and that this is our fault. Now nobody force anyone to use Pharo. We will continue and I'm confident that we will have success. Stef On Sat, Jan 13, 2018 at 2:01 PM, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Blame support P7 >>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. > > +1000 > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Stephane Ducasse

> > > > Am 13.01.2018 um 05:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Stephane, > > On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi torsten >> >> we have a super long list of *important* fixes and enhancements to do. > > > 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? > > > Sure it is important. If you would ask if anyone considers this as not > important youâll have a hard time finding many. That is not the point. If > everyone stays in its own personal context and judges from there it is > obvious that most decisions outside look non-sense from there. > This community is about collaboration. And collaboration does not mean that > everyone understands everyone elseâs decision. It means that if you donât > understand a decision from someone you still be able to believe he has good > reason to do so. > > > If the community is about collaboration then one prioritizes that which > promotes collaboration and fixing that which hinders it. Good that you mention that. Now I will not reply more because you will not really be able to understand my concerns about the way the VM is managed in a so community friendly way. About git support some companies told us that GIT support is KEY for them and it will be Key for the expansion of Pharo. Stef

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Benoit St-Jean

>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. Â +1000 ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Stephane Ducasse

Hi eliot Why do you attack me personally on this? I paid with my team money the salary of clement to work with you and I never said a word on the direction. So I would appreciate that you respect me. Thanks in advance for your understanding. Personally I would like to have a Pharo VM that does not crash when I type because of keybinding and freetype. And many more usability concerns. I will not reply to this thread anymore because I do not like to be insulted. Stef On Sat, Jan 13, 2018 at 5:22 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Stephane, > > On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi torsten >> >> we have a super long list of *important* fixes and enhancements to do. > > > 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? > >> >> >> Stef >> >> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> > Not having timestamps/authors in Pharo 7 due to git and missing blame >> > support >> > (see [1]) has other bad side effects: >> > >> > >> > - it clobbers all method stamps in an MCZ package [1] if you use >> > Monticello >> > which can lead easily to trouble/lamenting >> > >> > - it is not possible to fileout a changeset [2] in the ChangeSorter >> > >> > Was there any further discussion/decision for P7 on solving this >> > or adding blame support? >> > >> > Thx >> > T. >> > >> > >> > [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html >> > [2] >> > http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html >> > [3] https://pharo.fogbugz.com/f/cases/20951/ >> > >> > > > > -- > _,,,^..^,,,_ > best, Eliot

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Benoit St-Jean

> So what would be the alternative? A centralized server (e.g. Cincom Public Repository, SqueakSource, SmalltalkHub, SqueakSource 3).Â After that, all you need is a detailed project/package/framework description.Â Google will index it. The whole "GitHub adventure" was started on the premise that it would give Pharo more visibility.Â I don't see how it differs from SqueakSource from a visibility standpoint unless you specifically search for code only on GitHub.Â Most people just google anyway! Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers.Â I was recently told "I just gave up on Smalltalk when I saw 200+ files"...Â It was too late.Â I told the poor guy it was just the way code was *stored* on GitHub but in your dev environment, everything resides in the image...Â Too late : I had lost him solely based on the impression that he was entering into a code management nightmare worse than a thousand C header files! In the current state of things, the whole Cuis/Pharo/Squeak world is a mess.Â Newcomers looking for code end up having to pick between a myriad of links to SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz files, fileOuts, etc. Ever tried to do some database stuff with Squeak or Pharo?Â Just try to pick a package that works!Â You'll find plenty of code on all platforms (SqueakSource, SqueakMap, SS3, GitHub), many ports from one to the other and, in the end, you'll have tried to load 8 packages without success... Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak (and/or others such as VW, VAST, Dolphin) and share a common import/export format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and would probably do a decent job) and have the capability to store *other files* as well (such as config files, source code in other languages, SQL scripts, etc). Something with the functionalities/capabilities of Store (VW code management) with code store in a portable format. My 2 cents. Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: Norbert Hartl <norbert(a)hartl.name> To: Pharo Dev <pharo-dev(a)lists.pharo.org> Sent: Saturday, January 13, 2018 7:13 AM Subject: Re: [Pharo-dev] Blame support P7 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 Cyril Ferlicot D.

Le 13/01/2018 Ã 13:46, Norbert Hartl a Ã©critÂ : > > Sounds great! In which class is the code that does the decision about the right name? I think I find my convention here.+ > There is MethodClassifier with pragma, prefix and suffix map class side. > Norbert > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Jan. 13, 2018

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

by Norbert Hartl

> Am 13.01.2018 um 13:36 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > 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 +1

Jan. 13, 2018