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 torsten we have a super long list of *important* fixes and enhancements to do. Stef On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@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/
Donât you think having Author and timestamps is important?
Am 12.01.2018 um 10:26 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi torsten
we have a super long list of *important* fixes and enhancements to do.
Stef
On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@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/
2018-01-12 21:23 GMT+01:00 Norbert Hartl <norbert@hartl.name>:
Donât you think having Author and timestamps is important?
Glad to see Pharo Community waking up :) I felt a bit alone since I complained about that in last November ('about SortFunctions' thread)
Am 12.01.2018 um 10:26 schrieb Stephane Ducasse <stepharo.self@gmail.com :
Hi torsten
we have a super long list of *important* fixes and enhancements to do.
Stef
On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@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/
Am 12.01.2018 um 21:50 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2018-01-12 21:23 GMT+01:00 Norbert Hartl <norbert@hartl.name>:
Donât you think having Author and timestamps is important?
Glad to see Pharo Community waking up :) I felt a bit alone since I complained about that in last November ('about SortFunctions' thread)
I donât think it slept. There are just too much important things to do. So a temporary sacrifice is sometimes necesssary.
Am 12.01.2018 um 10:26 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Hi torsten
we have a super long list of *important* fixes and enhancements to do.
Stef
On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@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/
On 13 January 2018 at 04:50, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2018-01-12 21:23 GMT+01:00 Norbert Hartl <norbert@hartl.name>:
Donât you think having Author and timestamps is important?
Glad to see Pharo Community waking up :) I felt a bit alone since I complained about that in last November ('about SortFunctions' thread)
I've recently started using Pharo 7 and found it disconcerting when troubleshooting not knowing how old a method is or have any hint who might be familiar with it. IIUC the loss of author/timestamps is a consequence of merge conflicts in version information. I don't have a good grasp of the background on this though. I can't remember seeing a reproducible use case presented to the community to solve. Probably I was too busy and missed the discussion. Could someone link to a past steps to reproduce? Or now we have new Tonel files, how we can reintroduce version info code into a branch so we can experiment with solutions? I had a vague idea where version-info was kept in a separate file to the Tonel file. Each time the Tonel file is updated, its associated version-info is written to a *new* file. The hash of the Tonel file would form part of the version-info filename so you can always find the version-info file for a given Tonel file if they become separated. This might avoid version conflicts since whole version-info files are never modified, only deleted and added. cheers -ben
Am 12.01.2018 um 10:26 schrieb Stephane Ducasse < stepharo.self@gmail.com>:
Hi torsten
we have a super long list of *important* fixes and enhancements to do.
Stef
On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@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-td49684 72.html [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-Janu ary/026350.html [3] https://pharo.fogbugz.com/f/cases/20951/
Hi Stephane, On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@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@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
Eliot Miranda <eliot.miranda@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. Stephan
Hi Stephan,
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Eliot Miranda <eliot.miranda@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)
Am 13.01.18 um 12:39 schrieb Eliot Miranda:
Hi Stephan,
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Eliot Miranda <eliot.miranda@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
Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Stephan,
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Eliot Miranda <eliot.miranda@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)
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@hartl.name> To: Pharo Dev <pharo-dev@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@gmail.com>: Hi Stephan, On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote: Eliot Miranda <eliot.miranda@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)
Hi Norbert,
On Jan 13, 2018, at 4:12 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Stephan,
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Eliot Miranda <eliot.miranda@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)
On 13 January 2018 at 20:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> 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. What happens if two concurrent commits modify the same method but not the same lines? Is it a conflict like in MC? If yes, then there is nothing stopping the last author/timestamp metadata to be included in source files (either directly or in a sister file). The problem we had previously with metadata was that it did include history which necessarily conflicts... (Or not, there was a viable specific merge developped for that case, may I remind https://github.com/ThierryGoubier/GitFileTree-MergeDriver) Also the format was not adequate initially (single line in the eyes of git). Author and timestamp are somehow redundant with git own metadata... Or not if there are exchange with other flavours an other backends. 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 <btc@openinworld.com>:
On 13 January 2018 at 20:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl>
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.
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/Documentati... 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
Eliot Miranda <eliot.miranda@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
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)
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Eliot Miranda <eliot.miranda@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
Am 13.01.2018 um 05:22 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@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. my 2 cents, Norbert
Stef
On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@gmx.de <mailto:astares@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 <http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html> [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html <http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html> [3] https://pharo.fogbugz.com/f/cases/20951/ <https://pharo.fogbugz.com/f/cases/20951/>
-- _,,,^..^,,,_ best, Eliot
On Jan 13, 2018, at 2:28 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 13.01.2018 um 05:22 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@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.
my 2 cents,
Norbert
Stef
On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares@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
Am 13.01.2018 um 05:22 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@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
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@gmail.com> wrote:
Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@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@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
Hi Stéphane,
On Jan 13, 2018, at 5:00 AM, Stephane Ducasse <stepharo.self@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@gmail.com> wrote: Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@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@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
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@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@gmail.com> wrote: Hi Stephane,
On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse <stepharo.self@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@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
On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda@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@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/
Hi Sven,
On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda@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@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/
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)
On 13 Jan 2018, at 15:13, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Sven,
On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda@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
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 <astares@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/
On Jan 13, 2018, at 7:49 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2018, at 15:13, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Sven,
On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda@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
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 <astares@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/
On Sat, Jan 13, 2018 at 04:49:07PM +0100, Sven Van Caekenberghe wrote:
On 13 Jan 2018, at 15:13, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Sven,
On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda@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
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
Sven Van Caekenberghe <sven@stfx.eu> 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 <stephan@stack.nl>:
Sven Van Caekenberghe <sven@stfx.eu> 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!
participants (12)
-
Andreas Wacknitz -
Ben Coman -
Benoit St-Jean -
David T. Lewis -
Eliot Miranda -
Esteban A. Maringolo -
Nicolas Cellier -
Norbert Hartl -
Stephan Eggermont -
Stephane Ducasse -
Sven Van Caekenberghe -
Torsten Bergmann