Re: [Pharo-dev] Blame support P7

[Esteban A. Maringolo]

2018-01-14 8:04 GMT-03:00 Stephan Eggermont :
>
> Sven Van Caekenberghe  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!

Re: [Pharo-dev] Blame support P7

[Stephan Eggermont]

Sven Van Caekenberghe  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

Re: [Pharo-dev] Blame support P7

[David T. Lewis]

On Sat, Jan 13, 2018 at 04:49:07PM +0100, Sven Van Caekenberghe wrote:
> 
> 
> > On 13 Jan 2018, at 15:13, Eliot Miranda  wrote:
> > 
> > Hi Sven,
> > 
> >> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe  wrote:
> >> 
> >> 
> >> 
> >>> On 13 Jan 2018, at 05:22, Eliot Miranda  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

Re: [Pharo-dev] Blame support P7

[David T. Lewis]

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

Re: [Pharo-dev] Blame support P7

[Nicolas Cellier]

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 :

> On 13 January 2018 at 20:12, Norbert Hartl  wrote:
> >>
> >> Am 13.01.2018 um 12:39 schrieb Eliot Miranda :
> >>
> >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont 
> 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 

Re: [Pharo-dev] Blame support P7

[Ben Coman]

On 13 January 2018 at 20:57, Benoit St-Jean via Pharo-dev
<pharo-dev@lists.pharo.org> wrote:
>
>
> -- Forwarded message --
> From: Benoit St-Jean <bstj...@yahoo.com>
> To: Pharo Development List <pharo-dev@lists.pharo.org>
> 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

Re: [Pharo-dev] Blame support P7

[Ben Coman]

On 13 January 2018 at 20:12, Norbert Hartl  wrote:
>>
>> Am 13.01.2018 um 12:39 schrieb Eliot Miranda :
>>
>> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  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.

Re: [Pharo-dev] Blame support P7

[Eliot Miranda]

> On Jan 13, 2018, at 7:49 AM, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 13 Jan 2018, at 15:13, Eliot Miranda  wrote:
>> 
>> Hi Sven,
>> 
>>> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe  wrote:
>>> 
>>> 
>>> 
 On 13 Jan 2018, at 05:22, Eliot Miranda  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  wrote:
> Not having 

Re: [Pharo-dev] Blame support P7

[Sven Van Caekenberghe]

> On 13 Jan 2018, at 15:13, Eliot Miranda  wrote:
> 
> Hi Sven,
> 
>> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe  wrote:
>> 
>> 
>> 
>>> On 13 Jan 2018, at 05:22, Eliot Miranda  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  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: [Pharo-dev] Blame support P7

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
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)
--- End Message ---

Re: [Pharo-dev] Blame support P7

[Sven Van Caekenberghe]

> On 13 Jan 2018, at 14:21, Stephane Ducasse  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 reay 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

Re: [Pharo-dev] Blame support P7

[Eliot Miranda]

Hi Norbert,


> On Jan 13, 2018, at 4:12 AM, Norbert Hartl  wrote:
> 
> 
> 
>> Am 13.01.2018 um 12:39 schrieb Eliot Miranda :
>> 
>> Hi Stephan,
>> 
>> 
>>> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  wrote:
>>> 
>>> Eliot Miranda 
>>> 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)
> 

Re: [Pharo-dev] Blame support P7

[Eliot Miranda]

Stef,

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

_,,,^..^,,,_ (phone)

> On Jan 13, 2018, at 5:00 AM, Stephane Ducasse  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  
>> wrote:
>> Hi Stephane,
>> 
>> On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse 
>> 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  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
> 

Re: [Pharo-dev] Blame support P7

[Stephane Ducasse]

I think that some people are talking without really understanding. Let
me shed some light

- Iceberg uses the Monticello meta model to compute models and store
information in Git (files).
- Now Monticello just stores the information in zip files.
- In addition Pharo itself is doing the diff model and does not let
git doing the diff between models.
So I do not understand why Iceberg is less Smalltalk centric than Envy
or Store (BTW about store
I would have a lot to say about the industrial strength of the product
- one db expert look at the model
and he was reay surprised.).

- Now what Git gives us is that we can manage C, Pharo, PNG, css, 
the same way.
In addition you may not like git (I do not like git personally but I
really love the model) and we
need to have a real decentralized source versioning control system. We
are not afraid by sharing :)
and collaborating. The world is using Git and we are too.
The situation will improve and it will continue to improve.


Now it looks like the great smalltalk community does not like when
people get some traction.
I cannot do much for them. Do not participate, complain and tell us
that we are plain idiots and that this is our fault.
Now nobody force anyone to use Pharo.

We will continue and I'm confident that we will have success.

Stef




On Sat, Jan 13, 2018 at 2:01 PM, Benoit St-Jean via Pharo-dev
<pharo-dev@lists.pharo.org>
> Subject: Re: [Pharo-dev] Blame support P7
>>Then why on /earth/ would one stop using Smalltalk in /the most central part/ 
>>of the collaborative programming >process, version control?  This is a huge 
>>blunder.
>
> +1000
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
>
>

Re: [Pharo-dev] Blame support P7

[Eliot Miranda]

Hi Stéphane,

> On Jan 13, 2018, at 5:00 AM, Stephane Ducasse  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  
>> wrote:
>> Hi Stephane,
>> 
>> On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse 
>> 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  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
> 

Re: [Pharo-dev] Blame support P7

[Stephane Ducasse]

I think that some people are talking without really understanding. Let
me shed some light

- Iceberg uses the Monticello meta model to compute models and store
information in Git (files).
- Now Monticello just stores the information in zip files.
- In addition Pharo itself is doing the diff model and does not let
git doing the diff between models.
So I do not understand why Iceberg is less Smalltalk centric than Envy
or Store (BTW about store
I would have a lot to say about the industrial strength of the product
- one db expert look at the model
and he was reay surprised.).

- Now what Git gives us is that we can manage C, Pharo, PNG, css, 
the same way.
In addition you may not like git (I do not like git personally but I
really love the model) and we
need to have a real decentralized source versioning control system. We
are not afraid by sharing :)
and collaborating. The world is using Git and we are too.
The situation will improve and it will continue to improve.


Now it looks like the great smalltalk community does not like when
people get some traction.
I cannot do much for them. Do not participate, complain and tell us
that we are plain idiots and that this is our fault.
Now nobody force anyone to use Pharo.

We will continue and I'm confident that we will have success.

Stef




On Sat, Jan 13, 2018 at 2:01 PM, Benoit St-Jean via Pharo-dev
<pharo-dev@lists.pharo.org>
> Subject: Re: [Pharo-dev] Blame support P7
>>Then why on /earth/ would one stop using Smalltalk in /the most central part/ 
>>of the collaborative programming >process, version control?  This is a huge 
>>blunder.
>
> +1000
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
>
>

Re: [Pharo-dev] Blame support P7

[Stephane Ducasse]

>
>
>
> Am 13.01.2018 um 05:22 schrieb Eliot Miranda :
>
> Hi Stephane,
>
> On Fri, Jan 12, 2018 at 1:26 AM, Stephane Ducasse 
> 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

Re: [Pharo-dev] Blame support P7

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
>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)



   --- End Message ---

Re: [Pharo-dev] Blame support P7

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
> 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 <norb...@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.mira...@gmail.com>:
Hi Stephan,



On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <step...@stack.nl> wrote:

Eliot Miranda <eliot.mira...@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)



   --- End Message ---

Re: [Pharo-dev] Blame support P7

[Stephan Eggermont]

Eliot Miranda 
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

Re: [Pharo-dev] Blame support P7

[Norbert Hartl]

> Am 13.01.2018 um 12:39 schrieb Eliot Miranda :
> 
> Hi Stephan,
> 
> 
>> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  wrote:
>> 
>> Eliot Miranda 
>> 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)

Re: [Pharo-dev] Blame support P7

[Andreas Wacknitz]

Am 13.01.18 um 12:39 schrieb Eliot Miranda:
> Hi Stephan,
>
>
>> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  wrote:
>>
>> Eliot Miranda 
>> 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

Re: [Pharo-dev] Blame support P7

[Eliot Miranda]

> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  wrote:
> 
> Eliot Miranda 
> 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
> 
> 

Re: [Pharo-dev] Blame support P7

[Eliot Miranda]

Hi Stephan,


> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont  wrote:
> 
> Eliot Miranda 
> 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)

Re: [Pharo-dev] Blame support P7

[Stephan Eggermont]

Eliot Miranda 
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

Re: [Pharo-dev] Blame support P7

[Norbert Hartl]

Don‘t you think having Author and timestamps is important?

> Am 12.01.2018 um 10:26 schrieb Stephane Ducasse :
> 
> 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  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/
>>