> On 13 Jan 2018, at 15:13, Eliot Miranda <[email protected]> wrote: > > Hi Sven, > >> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <[email protected]> wrote: >> >> >> >>> On 13 Jan 2018, at 05:22, Eliot Miranda <[email protected]> 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 <[email protected]> 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/
