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

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

Hi Sven, > On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 13 Jan 2018, at 05:22, 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? > > Eliot, > > Not trying to minimise your contributions (we all love the VM), and I know that you favour collaboration, but > > (1) what non-trivial code is actively maintained from a single code base between Pharo, Squeak and Cuis ? Alien > (2) how/where are you developing in Pharo ? I only see you contributing to Squeak, where only a handful of very experienced developers are making occasional, conservative changes to maintain their own environment. You may be using the 64-bit version of Pharo. That is my work. If you're using the FFI then I've had a part in it (callbacks being the most specific). And the new release will use the Sista bytecode set. That's me and ClÃ©ment. ClÃ©ment and others integrate stuff on my behalf. I also work closely with people in the Pharo community and get work from users of Pharo. Pharo is important to me. But this isn't about me. I disagree with your description of the Squeak community. St Potsdam it is used by students. The raspberry pi scratch was in Squeak until late last year. It is not as you describe. > > For me, and many others the VM is a completely closed ecosystem, a black box. A know the simulator is cool, but I have never seen it. What does that have to do with this discussion? > Your choice to use Squeak is a valid one that probably makes sense to you, but you must also respect the successful alternative that Pharo is. Again how does my criticisms my the git integration have anything to do with Pharo being a successful alternative? Do you think I want Pharo to fail? Do you think I would bother commenting if I wasn't interested? > > Sven > >> 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/ >>> >> >> >> >> > >

Jan. 13, 2018

Re: [Pharo-dev] ZnClient issue: ZdcPlugin Missing

by Sven Van Caekenberghe

can you paste that expression/URL in text so that I can try myself ? > On 13 Jan 2018, at 14:31, Photon <nico-braun(a)live.de> wrote: > > Ok i deleted the whole folder and downloaded it again. unzipped it an run a > fresh image. > It is allmost funny because now i get a different error: Instance of byte > array did not understand #lines > i tried again both expressions and together. With and without lines. I even > put a # in front of the array. > Nothing works. See picture below. > > > > <http://forum.world.st/file/t371759/bytearray.png> > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Sven Van Caekenberghe

> On 13 Jan 2018, at 05:22, 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? Eliot, Not trying to minimise your contributions (we all love the VM), and I know that you favour collaboration, but (1) what non-trivial code is actively maintained from a single code base between Pharo, Squeak and Cuis ? (2) how/where are you developing in Pharo ? I only see you contributing to Squeak, where only a handful of very experienced developers are making occasional, conservative changes to maintain their own environment. For me, and many others the VM is a completely closed ecosystem, a black box. A know the simulator is cool, but I have never seen it. Your choice to use Squeak is a valid one that probably makes sense to you, but you must also respect the successful alternative that Pharo is. Sven > 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/ > > > > > >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Sven Van Caekenberghe

> On 13 Jan 2018, at 14:21, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > 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. This is a clear, factual and to the point response, and I fully agree, let's move on. Sven

Jan. 13, 2018

Re: [Pharo-dev] Protocol names convention

by Alistair Grant

On 13 January 2018 at 13:50, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > 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. Which is called by NautilusUI>>compileAMethodFromCategory:withSource:notifying: Cheers, Alistair

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

Hi Norbert, > On Jan 13, 2018, at 4:12 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> 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. Nearly the same is not all the same ;-). Somehow the export through gif is fiffetebt; it has been losing the time stamp metadata for ages (I was noticed gong this in Esteban's VMMaker commits at least a year ago) and still it doesn't work. But a big difference is that the Monticello mcz package (only one among many formats) uses zip file support written in Smalltalk (from which a vm plugin is generated) and the zip file format is much sikmpler as an API than the API needed to integrate with git. Another difference is that, because hot is a version control system in its own right, integrating with it is a poison pill. People will (and do!) want to use their own git tools and so the pressure is on to make Smalltalk fit git rather than got fit Smalltalk, to put effort on the git side instead of improving the Monticello side. And the other difference is the number and nature of the crashes with the git integration. There are crashes in c libraries. There are certificate problems. There are password problems. The surface is much larger and do there are more problems. > The exchange is necessary because the possibilities of collaboration are limited when using monticello only. So what would be the alternative? BenoÃ®t answered this well. But as they say, there are many ways to skin a cat. With the right statement of principles the right kind of integration might be definable. For example, with a class per file approach has anyone considered publishing two files, one that preserves all data and another that is designed for GitHub's code diffing? > 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. Git can do nothing that Monticello cannot do except manage external files. But extending Monticello to manage external files is possible because we control it. GitHub, on the other hand, /is/ different. It provides a social platform, issue tracking, and a globally recognized brand. I use both git and Monticello in the vm work and Monticello is a joy to work with. I wish I could say the same for git. I do think that github is good. I do wish that it wasn't so git-centric :-( > 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. Not at all. Monticello scales to the entire Pharo and Squeak community so it cannot be the limiting factor on the size of the vm sub culture. And of bourse putting the generated C code on GitHub has been a huge improvement over Subversion. But the vm maintains a comfortable split between VMMaker & Smalltalk under Monticello and the generated C under git & GitHub. > Norbert > >>> >>> Stepha >> >> _,,,^..^,,,_ (phone) >

Jan. 13, 2018

Re: [Pharo-dev] ZnClient issue: ZdcPlugin Missing

by Photon

Ok i deleted the whole folder and downloaded it again. unzipped it an run a fresh image. It is allmost funny because now i get a different error: Instance of byte array did not understand #lines i tried again both expressions and together. With and without lines. I even put a # in front of the array. Nothing works. See picture below. <http://forum.world.st/file/t371759/bytearray.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 13, 2018

Re: [Pharo-dev] [Doodle] OpenSmalltalk VM Meeting

by Fabio Niephaus

Hi all, This is a friendly reminder that you can still sign up for the below until tomorrow evening. Best, Fabio -- On Mon, Jan 8, 2018 at 8:46 PM Fabio Niephaus <lists(a)fniephaus.com> wrote: > Hi all, > > When ClÃ©ment and I recently talked about the next VM release, we thought > it might be good to organize a meeting and invite everyone who would be > interested. The agenda is yet to be finalized, but I think it would be > great if ClÃ©ment and/or Eliot could give an update on their work on Sista. > And I could give an overview of what still needs to be done for the release > or how we plan to sign and update the release bundles. I'm sure there is a > lot more we can talk about. > > If you would like to attend, please indicate your availability using this > Doodle link by Sunday, 14th January: > https://doodle.com/poll/cyei4ax4sd43m522. > > Looking forward to seeing you all soon. > > Best, > Fabio >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

Stef, compare your response below with the considered responses from Stephan Eggermont (on why newbies have a different experience from experts) and BenoÃ®t (on alternatives to github). You have some work you need to do in yourself to try and control your emotions. You resound while still upset. We all get upset, but it is wise to cool off before responding. Your community needs you, but a mature, reflective and intelligent you, not an explosive you. _,,,^..^,,,_ (phone) > 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 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 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