Blame support P7
Locked
12
12
 
|
Hi Stéphane,
> On Jan 13, 2018, at 5:00 AM, Stephane Ducasse <[hidden email]> 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 <[hidden email]> wrote: >> Hi Stephane, >> >> On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <[hidden email]> >> 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 <[hidden email]> 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 > |
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
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 <[hidden email]> > 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) > > > > |
|
|
In reply to this post by Stephane Ducasse-3
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 <[hidden email]> 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 <[hidden email]> wrote: >> Hi Stephane, >> >> On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <[hidden email]> >> 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 <[hidden email]> 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 > |
|
|
In reply to this post by NorbertHartl
Hi Norbert,
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.
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 :-(
|
|
|
In reply to this post by Stephane Ducasse-3
> On 13 Jan 2018, at 14:21, Stephane Ducasse <[hidden email]> 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 |
|
|
In reply to this post by Eliot Miranda-2
> On 13 Jan 2018, at 05:22, Eliot Miranda <[hidden email]> 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 <[hidden email]> 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/ > > > > > > |
|
|
Hi Sven,
> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <[hidden email]> wrote: > > > >> On 13 Jan 2018, at 05:22, Eliot Miranda <[hidden email]> 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 <[hidden email]> 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/ >>> >> >> >> >> > > |
Re: Blame support P7
|
|
Just a reminder... We're only 13 days into the new year... Let's take a deep breath everyone... We're all smalltalkers : I'm sure we can discuss all this in a civilized way, with arguments and good manners in a joyful and respectful atmosphere! We're not at war : we are exchanging ideas! If we didn't care about Pharo/Squeak/Cuis/Dolphin/OS/VW/VAST/Whatever, we wouldn't criticize at all. "On critique bien ceux que l'on aime bien" :) ----------------- 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) |
|
|
In reply to this post by Eliot Miranda-2
> On 13 Jan 2018, at 15:13, Eliot Miranda <[hidden email]> wrote: > > Hi Sven, > >> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <[hidden email]> wrote: >> >> >> >>> On 13 Jan 2018, at 05:22, Eliot Miranda <[hidden email]> 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 Hmm, not that active. And it requires Pharo/Cuis to use an 'older' loading mechanism (from their perspective evolving to git SCM). Other than that, a very short list. You know just as well as that it is close to impossible to do this (Seaside and FUEL are the only real counter examples, and even there it is a lot of work). >> (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 started by saying that I know and appreciate your work. Since I did not say anything otherwise, you do not need to get defensive. "They integrate an my behalf" is exactly my point: you do something in your closed world and others can follow. > 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. It is and you know it. >> 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? Because you argue about collaboration while you act in a certain way. Again, I am fine if you make certain choices, everyone does, but you cannot ask others to do what you do no do yourself. >> 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? SCM and moving to git was argued about ad infinitum for years, Pharo (and others) are moving to it since a very long time. We're not there yet, but progress is good. (And yes the timestamps have to come back, the history is another issue). Starting 2018 by attacking that all that work is very cool indeed ;-) Stef explained factually how we still maintain enough modelling in Smalltalk. >> Sven >> >>> Stef >>> >>>> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <[hidden email]> 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/ |
|
|
> On Jan 13, 2018, at 7:49 AM, Sven Van Caekenberghe <[hidden email]> wrote: > > > >> On 13 Jan 2018, at 15:13, Eliot Miranda <[hidden email]> wrote: >> >> Hi Sven, >> >>> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> >>> >>>> On 13 Jan 2018, at 05:22, Eliot Miranda <[hidden email]> 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 > > Hmm, not that active. And it requires Pharo/Cuis to use an 'older' loading mechanism (from their perspective evolving to git SCM). Alien contains callbacks. As such, fundamental parts of Pharo depend on it. And your comment "use an 'older' loading mechanism" demonstrates that the git integration is not simply a back-end, but is affecting Monticello, IMO not for the better. > Other than that, a very short list. You know just as well as that it is close to impossible to do this (Seaside and FUEL are the only real counter examples, and even there it is a lot of work). I disagree. The core of refactoring (all except a small tool layer) is in common. And there are numerous compatibility packages out there, grease, but also, as in the refactoring engine, a common core with small Foo-Platform-Pharo & Foo-Platform-Squeak etc. I think to home up with an accurate picture free of our differences my opinions we would have to make a list. > >>> (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 started by saying that I know and appreciate your work. Since I did not say anything otherwise, you do not need to get defensive. I'm not being defensive. You made this personal. I wanted to state that I have made contributions to contradict your assertion that. Eye be the vm I did not. But I have nothing to feel defensive about. On the contrary I care about the collaboration between different communities above the common vm, and I care deeply; I gave skin in the game. > > "They integrate an my behalf" is exactly my point: you do something in your closed world and others can follow. How is "my world" my world, and how is it closed? >> 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. > > It is and you know it. I'd appreciate it if you would refrain from projecting on me. I'm not in the habit of lying. It isn't. You're entitled to your opinion as I am to mine. > >>> 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? > > Because you argue about collaboration while you act in a certain way. Again, I am fine if you make certain choices, everyone does, but you cannot ask others to do what you do no do yourself. Again you presume to know about my actions. I don't presume to know about your activities. > >>> 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? > > SCM and moving to git was argued about ad infinitum for years, Pharo (and others) are moving to it since a very long time. We're not there yet, but progress is good. (And yes the timestamps have to come back, the history is another issue). Starting 2018 by attacking that all that work is very cool indeed ;-) > > Stef explained factually how we still maintain enough modelling in Smalltalk. > >>> Sven >>> >>>> Stef >>>> >>>>> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <[hidden email]> 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/ > > |
|
|
In reply to this post by Pharo Smalltalk Developers mailing list
On 13 January 2018 at 20:57, Benoit St-Jean via Pharo-dev
<[hidden email]> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <[hidden email]> > To: Pharo Development List <[hidden email]> > Cc: > Bcc: > Date: Sat, 13 Jan 2018 12:57:00 +0000 (UTC) > Subject: Re: [Pharo-dev] Blame support P7 >> 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. From what I remember of mail list discussions, the primary reason to move to github, which was reducing the need for a 24x7 operations team to support our code repository servers. http://forum.world.st/SmalltalkHub-bugs-hangs-tp4792551p4792598.html There was an argument that support effort would make the servers more reliable, but it seems both SqueakSource3 and Smalltalkhub were started in response to SqueakSource issues at some time. So ti still seems reasonable to make use of these 3rd party maintained VCS services. > > 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! Which repo was that? Was it before/after Tonel? > 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. > 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) Yes, but please not XML. JSON like would be much nicer, where Tonel could be a good option. cheers -ben |
|
|
In reply to this post by NorbertHartl
On 13 January 2018 at 20:12, Norbert Hartl <[hidden email]> wrote:
>> >> Am 13.01.2018 um 12:39 schrieb Eliot Miranda <[hidden email]>: >> >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <[hidden email]> wrote: >>> >>> 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? I sure Eliot referred to the external C library of libgit2 regarding stepping outside of the Smalltalk environment. Its the root source of the segfaults that is killing the reliability. > 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? The alternative would be a Smalltalk implementation of git. This would surely reduce segfaults and make debugging easier with a wider pool of contributors. The downside would be tracking the evolution of git. Perhaps when libgit2 was selected the balance was foreseen in its favour. However with current experience perhaps this balance is worth review. For POC, here are some other language native implementations of git... http://www.eclipse.org/jgit/ https://github.com/jelmer/dulwich https://github.com/mirage/ocaml-git https://github.com/danlucraft/git.js https://github.com/henon/GitSharp THIS ARTICLE is really informative... http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ Can anyone here familiar with Haskell help with converting those code examples to Smalltalk? @Eliot, Given that Pharo is likely to continue down the git path, how interested do you think the Squeak community would be in a Smalltalk implementation of git to facilitate future collaboration. Maybe the question could be raised there separately? @Juan, IIUC Cuis already primarily uses git for Smalltalk source code management. How is this currently done and would you partake in a Smalltalk implementation of git? > 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. Simply we either stay the same; Or we move. Moving does risk that a wrong path is started, or we go a long way round, but even on a non-optimal paths much can be learnt. Pharo zen is "Learning from mistakes." and while I don't believe libgit2 was a mistake since it allowed Iceberg development to start at a higher level, perhaps replacing it with a native Smalltalk implementation is worth a trial. Some subparts of this might make a good GSoC project (?) cheers -ben P.S. No-one has mentioned the "content addressable" nature of git which I believe is the *real* paradigm shift in VCS that we should pursue. With a CompiledMethod referencing a hash of its method-source rather than a location in a particular file on a filesystem, opens the possibility of a dozen different providers for locating that method-source that are all equivalent and substitutable with one another for maintaining compatibility between Smalltalk dialects. The hash could reference a "git object" of that hash, or an entity on IPFS (https://ipfs.io) or http://my.simpleServer.com/methodhash. |
|
|
There is obviously some kind of resentment and tension unrelated to this thread. If the result is that we can't dicuss possible solutions, then it's bad, because this is an important point.(Or not, there was a viable specific merge developped for that case, may I remind https://github.com/ Also the format was not adequate initially (single line in the eyes of git).The very first exchange is the one way conversion to iceberg which magically erase all the metadata. Please note that these data are not temporary lost but definitely, so it's indeed a sacrifice. Then if I pick a method verbatim from Squeak to Pharo or Pharo to Squeak, that doesn't make me an author.If I wish to maintain cross compatibility for a library that means exchanging too. Minimizing the existence of such libraries or the will of maintainers is like counting a whole part of this community for nothing. If I speculate on the intentions, which is a bit dangerous in such explosive atmosphere, what are the plans for restoring the most elementary features of a VCS that are authorship and history? Use git data exclusively? 2018-01-13 17:52 GMT+01:00 Ben Coman <[hidden email]>: On 13 January 2018 at 20:12, Norbert Hartl <[hidden email]> wrote: |
|
|
In reply to this post by Ben Coman
On Sun, Jan 14, 2018 at 12:52:52AM +0800, Ben Coman wrote:
> > @Juan, IIUC Cuis already primarily uses git for Smalltalk source code management. > How is this currently done and would you partake in a Smalltalk > implementation of git? > You will find Juan's explanation of Git and GitHub for Cuis code management at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/CuisAndGitHub.md The introduction to that explanation is worth quoting here: > Cuis includes tools and procedures for managing Smalltalk code. Central > to this is the management of Packages and Package Files (.pck). But Cuis > doesn't do version control. Instead, we suggest using external VCS tools. > In particular, we're using GitHub, and the first project we're hosting > there is StyledTextEditor. > > The guiding principle is to not duplicate concepts and behavior. As we're > using an external tool (Git) for version control, then we use it as it > meant to be used. Most people use Git for version control and a file based > IDE such as Eclipse for development. Such IDEs don't do version control > themselves. It is done by Git. Do the same: do not include package version > control in Cuis. This is a departure from the Monticello /Git integration > (smallsource and MonticelloFileTree) by Otto Behrens, Dale Henrichs, etc. Dave |
|
|
In reply to this post by Sven Van Caekenberghe-2
On Sat, Jan 13, 2018 at 04:49:07PM +0100, Sven Van Caekenberghe wrote:
> > > > On 13 Jan 2018, at 15:13, Eliot Miranda <[hidden email]> wrote: > > > > Hi Sven, > > > >> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <[hidden email]> wrote: > >> > >> > >> > >>> On 13 Jan 2018, at 05:22, Eliot Miranda <[hidden email]> 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 > > Hmm, not that active. And it requires Pharo/Cuis to use an 'older' loading mechanism (from their perspective evolving to git SCM). > > Other than that, a very short list. You know just as well as that it is close to impossible to do this (Seaside and FUEL are the only real counter examples, and even there it is a lot of work). > Indeed, Seaside and FUEL are good examples. My own experience is with OSProcess/CommandShell, which I develop in Squeak, version control in Monticello, and intermittently try to maintain for Pharo and Cuis. As you say, this can be difficult to do. Multiple version control approaches do not make the job any easier, and I can assure you that it does not make it any more enjoyable. I am probably not a good example, because I am just one person, not a development team. But for what it's worth, that is my experience. Dave |
|
|
In reply to this post by Sven Van Caekenberghe-2
Sven Van Caekenberghe <[hidden email]> wrote:
> (1) what non-trivial code is actively maintained from a single code base > between Pharo, Squeak and Cuis ? That is nice, but too limited a question What about the need to maintain non-trivial large code bases between multiple smalltalks? If we only limit ourselves to open source, just look at Glorp and PDFTalk. Stephan |
|
|
2018-01-14 8:04 GMT-03:00 Stephan Eggermont <[hidden email]>:
> > Sven Van Caekenberghe <[hidden email]> wrote: > > > (1) what non-trivial code is actively maintained from a single code base > > between Pharo, Squeak and Cuis ? > > That is nice, but too limited a question > > What about the need to maintain non-trivial large code bases between > multiple smalltalks? If we only limit ourselves to open source, just look > at Glorp and PDFTalk. I wouldn't use Glorp as a good example of multi-dialect portability. It has safeguards and "ifs" all around the code, but it goes more in the direction of making the dialects as much VW compatible as possible, instead of being truly dialect neutral like Seaside is, and have the proper "adapter" layer and packaging. Regards! |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |