Re: [Pharo-users] about balkanisation

[p...@highoctane.be]

On Thu, Nov 10, 2016 at 10:12 AM, Thierry Goubier  wrote:

> Hi Dale,
>
> 2016-11-10 6:04 GMT+01:00 Dale Henrichs 
> :
>
>>
>>
>> On 11/8/16 7:09 AM, Thierry Goubier wrote:
>>
>> Hi Dale,
>>
>> 2016-11-08 2:03 GMT+01:00 Dale Henrichs > >:
>>
>>> [ snip ... ]
>>>
>>> yes I think this is the area where a Metallo Project Browser comes into
>>> play. The technology for committing the dirty packages in a a
>>> ConfigurationOf has been around for quite awhile, but a tool that unifies
>>> the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped
>>> out of the wood work ...
>>>
>>
>> I'm having some issues with the scripting approach of Metacello, for
>> that. Just manipulating a baseline in the Metacello registry (locking it)
>> seems to be like writing a compiler code generation item: write a Metacello
>> script ;) (Metacello>>#lock contains interesting code).
>>
>> I think I agree:) ... that is why i am talking about a tool ...
>> developers shouldn't have to pass around workspaces to load and manipulate
>> projects .. a project tool can partially automate the process, but I
>> believe that there needs to be a "load spec" object that can be passed
>> around and massaged by code instead of requiring a user to edit a Smalltalk
>> workspace ... it's what I do in tODE ... the only times I have to write
>> Smalltalk load scripts is when I work in Pharo :)
>>
>
> Agreed. I would just like to find out which object can be used to act upon
> (can I call lock on a Metacello project spec... apparently not :))... I'm
> not too keen on adding another layer on top of it, first because I'm not
> that found of unneeded layers, second because it may mean a significant
> rewrite of the environment (have dozens of methods like MyLayer>>#load
> which is just a call to Metacello load) to get something that starts
> working.
>
> I'm not in a position to impose large scale changes in the Pharo
> ecosystem; it's the consortium role to take and impose such choices. I can
> only, like GitFileTree, inject something at a lower level that allow people
> to complement and experiment with...
>
>>
>>
>> I will repeat that I don't think Pharo should do exactly what I've done
>> with tODE, but a Metacello Project Browser and some sort of "load spec"
>> object that is shared amongst a cluster of images is something that needs
>> to be seriously considered ...
>>
>
> I'm really willing to also make something helping to work with Baselines /
> Configurations because I think they present a significant complexity
> barrier to the proper use of Metacello features, and I don't see any path
> avoiding us to write those, given how complex it may be.
>

Now a BaselineOf is a ConfigurationOf but such things cannot be put in the
Catalog because well, there is some incompatibility happening.

Getting BaselineOf usable right away would be a small step but a great step.

I find myself having to write a BaselineOf for the Git repo and a
ConfigurationOfXXX usign the old scheme to be put in the Catalog and
pointing to the BaselineOf.

Could someone point to the reason why?


>
>>
>>
>>>
>>>
>>> What is a bit annoying, really, is this talk of rewriting everything
>>> where some of the pieces (the project browsing you're talkin about, for
>>> example) is already there in the image, just not exposed.
>>>
>>> Well I am annoyed as well .. I would say that perhaps we are in
>>> screaming agreement ... I've said that I don't think it's a lot of work to
>>> do the project-centric tool. but a project-centric tool that encompasses
>>> both ConfigurationOf and BaselineOf will expose the features that "are
>>> already there"
>>>
>>>
>>> I'm trying to code a little something for that... stay tuned for a
>>> screenshot soon.
>>>
>>> Cool:)
>>>
>>
>> And here it is! I'm still fighting with the Metacello lock / unlock thing.
>>
>> [image: Images intégrées 1]
>>
>> If Pharo was more really modular in configurations and baselines, then I
>> would see more things into the registry and I could group packages based on
>> that (instead of having to prepare a ad-hoc classification for my my
>> browser).
>>
>> Yes this is headed in the right direction ... I am in Argentina this week
>> so it isn't easy for me to do much collaboration, but I would love to help
>> you with your lock problem next week ... For example ... you do not want to
>> directly expose the Metacello registry as there are "hybrid projects" where
>> a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs
>> to take precedence (I have code for resolving this) and I strongly suggest
>> that the Project Browser not be built-into the Class Browser, but be a
>> separate tool like the CataLogBrowser ... but this is just a suggestion ---
>> a separate tool dedicated only to loaded Projects and unloaded Projects of
>> interest allows one to get a very quick overview of what is in the project

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

Hi Dale,

2016-11-10 6:04 GMT+01:00 Dale Henrichs :

>
>
> On 11/8/16 7:09 AM, Thierry Goubier wrote:
>
> Hi Dale,
>
> 2016-11-08 2:03 GMT+01:00 Dale Henrichs 
> :
>
>> [ snip ... ]
>>
>> yes I think this is the area where a Metallo Project Browser comes into
>> play. The technology for committing the dirty packages in a a
>> ConfigurationOf has been around for quite awhile, but a tool that unifies
>> the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped
>> out of the wood work ...
>>
>
> I'm having some issues with the scripting approach of Metacello, for that.
> Just manipulating a baseline in the Metacello registry (locking it) seems
> to be like writing a compiler code generation item: write a Metacello
> script ;) (Metacello>>#lock contains interesting code).
>
> I think I agree:) ... that is why i am talking about a tool ... developers
> shouldn't have to pass around workspaces to load and manipulate projects ..
> a project tool can partially automate the process, but I believe that there
> needs to be a "load spec" object that can be passed around and massaged by
> code instead of requiring a user to edit a Smalltalk workspace ... it's
> what I do in tODE ... the only times I have to write Smalltalk load scripts
> is when I work in Pharo :)
>

Agreed. I would just like to find out which object can be used to act upon
(can I call lock on a Metacello project spec... apparently not :))... I'm
not too keen on adding another layer on top of it, first because I'm not
that found of unneeded layers, second because it may mean a significant
rewrite of the environment (have dozens of methods like MyLayer>>#load
which is just a call to Metacello load) to get something that starts
working.

I'm not in a position to impose large scale changes in the Pharo ecosystem;
it's the consortium role to take and impose such choices. I can only, like
GitFileTree, inject something at a lower level that allow people to
complement and experiment with...

>
>
> I will repeat that I don't think Pharo should do exactly what I've done
> with tODE, but a Metacello Project Browser and some sort of "load spec"
> object that is shared amongst a cluster of images is something that needs
> to be seriously considered ...
>

I'm really willing to also make something helping to work with Baselines /
Configurations because I think they present a significant complexity
barrier to the proper use of Metacello features, and I don't see any path
avoiding us to write those, given how complex it may be.


>
>
>>
>>
>> What is a bit annoying, really, is this talk of rewriting everything
>> where some of the pieces (the project browsing you're talkin about, for
>> example) is already there in the image, just not exposed.
>>
>> Well I am annoyed as well .. I would say that perhaps we are in screaming
>> agreement ... I've said that I don't think it's a lot of work to do the
>> project-centric tool. but a project-centric tool that encompasses both
>> ConfigurationOf and BaselineOf will expose the features that "are already
>> there"
>>
>>
>> I'm trying to code a little something for that... stay tuned for a
>> screenshot soon.
>>
>> Cool:)
>>
>
> And here it is! I'm still fighting with the Metacello lock / unlock thing.
>
> [image: Images intégrées 1]
>
> If Pharo was more really modular in configurations and baselines, then I
> would see more things into the registry and I could group packages based on
> that (instead of having to prepare a ad-hoc classification for my my
> browser).
>
> Yes this is headed in the right direction ... I am in Argentina this week
> so it isn't easy for me to do much collaboration, but I would love to help
> you with your lock problem next week ... For example ... you do not want to
> directly expose the Metacello registry as there are "hybrid projects" where
> a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs
> to take precedence (I have code for resolving this) and I strongly suggest
> that the Project Browser not be built-into the Class Browser, but be a
> separate tool like the CataLogBrowser ... but this is just a suggestion ---
> a separate tool dedicated only to loaded Projects and unloaded Projects of
> interest allows one to get a very quick overview of what is in the project
> or not and when version skew pops up, one can easily see the affected
> projects ... embedding this kind of information in the code browser can
> make it hard to get the overview and if you choose to live with version
> skew can be annoying to ignore  again these are just my thoughts ..
>

I'm of a different mind on this. Giving access to the Metacello registry
explains well to me what is happening in the system; as long as the GUI
accelerate a significant subset of the common operations, then I'll
consider it good enough and have it working on a short time frame.

Otherwise, you end up with projects like libgit / 

Re: [Pharo-users] about balkanisation

[Igor Stasenko]

On 10 November 2016 at 06:07, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 11/8/16 11:04 PM, Igor Stasenko wrote:
>
>
>
> On 7 November 2016 at 14:28, stepharo  wrote:
>
>>
>> [ ... ]
>>
>>
>> And this one I don't understand. A smooth, git / iceberg oriented
>> transition over Monticello/Metacello is perfectly doable... As Dale
>> explained. A nice Iceberg gui reworking / making git usable is perfect.
>>
>> But why make the transition so hard? You get Stef angry on a Sunday
>> morning because he can't find things anymore... even if he is a strong
>> proponent of the strategy he complains about ;)
>>
>>
>> No my point was not that.
>> My point is that it is important to pay attention and not to add more
>> noise than necessary. Let us take the time and move alltogether.
>>
>> If you want to get somewhere with this story, you don't want to wait till
> everything will be ready.
> Transition will never start unless you force users to enter the minefield
> and let them clear the mines for you. Step by step. Many will blow
> themselves up, while some will manage to pass unhurt..
> Because else, it will be always a minefield between you and the
> destination of your journey :)
>
> I think that at the early stages of the transition you have to support
> both approaches ... when the new tools are in place and stabilized then one
> can consider ... the transition has already started so this is not a case
> where you need to force folks to change, but a case where you need to
> support the folks who choose to change ... it can be relatively low cost to
> keep the old tools around for quite awhile ... I would think ...
>
>
Right, as i said: make a minefield and watch those who wanting to cross it.
And big mistake then to shout: hey i will never ever step on it.. This is
bad idea,
since you discouraging people from doing what you need :)


> Dale
>



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/8/16 11:04 PM, Igor Stasenko wrote:



On 7 November 2016 at 14:28, stepharo > wrote:



[ ... ]


And this one I don't understand. A smooth, git / iceberg oriented
transition over Monticello/Metacello is perfectly doable... As
Dale explained. A nice Iceberg gui reworking / making git usable
is perfect.

But why make the transition so hard? You get Stef angry on a
Sunday morning because he can't find things anymore... even if he
is a strong proponent of the strategy he complains about ;)


No my point was not that.
My point is that it is important to pay attention and not to add
more noise than necessary. Let us take the time and move alltogether.

If you want to get somewhere with this story, you don't want to wait 
till everything will be ready.
Transition will never start unless you force users to enter the 
minefield and let them clear the mines for you. Step by step. Many 
will blow themselves up, while some will manage to pass unhurt..
Because else, it will be always a minefield between you and the 
destination of your journey :)
I think that at the early stages of the transition you have to support 
both approaches ... when the new tools are in place and stabilized then 
one can consider ... the transition has already started so this is not a 
case where you need to force folks to change, but a case where you need 
to support the folks who choose to change ... it can be relatively low 
cost to keep the old tools around for quite awhile ... I would think ...


Dale

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/8/16 7:09 AM, Thierry Goubier wrote:

Hi Dale,

2016-11-08 2:03 GMT+01:00 Dale Henrichs 
>:


[ snip ... ]


yes I think this is the area where a Metallo Project Browser comes
into play. The technology for committing the dirty packages in a a
ConfigurationOf has been around for quite awhile, but a tool that
unifies the "multi-package" commit for ConfigurationOf and
BaselineOf hasn't popped out of the wood work ...


I'm having some issues with the scripting approach of Metacello, for 
that. Just manipulating a baseline in the Metacello registry (locking 
it) seems to be like writing a compiler code generation item: write a 
Metacello script ;) (Metacello>>#lock contains interesting code).
I think I agree:) ... that is why i am talking about a tool ... 
developers shouldn't have to pass around workspaces to load and 
manipulate projects .. a project tool can partially automate the 
process, but I believe that there needs to be a "load spec" object that 
can be passed around and massaged by code instead of requiring a user to 
edit a Smalltalk workspace ... it's what I do in tODE ... the only times 
I have to write Smalltalk load scripts is when I work in Pharo :)


I will repeat that I don't think Pharo should do exactly what I've done 
with tODE, but a Metacello Project Browser and some sort of "load spec" 
object that is shared amongst a cluster of images is something that 
needs to be seriously considered ...





What is a bit annoying, really, is this talk of rewriting
everything where some of the pieces (the project browsing you're
talkin about, for example) is already there in the image, just
not exposed.

Well I am annoyed as well .. I would say that perhaps we are in
screaming agreement ... I've said that I don't think it's a lot of
work to do the project-centric tool. but a project-centric tool
that encompasses both ConfigurationOf and BaselineOf will expose
the features that "are already there"


I'm trying to code a little something for that... stay tuned for
a screenshot soon.

Cool:)


And here it is! I'm still fighting with the Metacello lock / unlock thing.

Images intégrées 1

If Pharo was more really modular in configurations and baselines, then 
I would see more things into the registry and I could group packages 
based on that (instead of having to prepare a ad-hoc classification 
for my my browser).
Yes this is headed in the right direction ... I am in Argentina this 
week so it isn't easy for me to do much collaboration, but I would love 
to help you with your lock problem next week ... For example ... you do 
not want to directly expose the Metacello registry as there are "hybrid 
projects" where a ConfigurationOf causes a BaselineOf to be loaded, so 
the BaselineOf needs to take precedence (I have code for resolving this) 
and I strongly suggest that the Project Browser not be built-into the 
Class Browser, but be a separate tool like the CataLogBrowser ... but 
this is just a suggestion --- a separate tool dedicated only to loaded 
Projects and unloaded Projects of interest allows one to get a very 
quick overview of what is in the project or not and when version skew 
pops up, one can easily see the affected projects ... embedding this 
kind of information in the code browser can make it hard to get the 
overview and if you choose to live with version skew can be annoying to 
ignore  again these are just my thoughts ..


Regardless I think you are definitely headed in the right direction and 
it isn't all that much work ... yet:)


Dale

Re: [Pharo-users] about balkanisation

[Igor Stasenko]

On 7 November 2016 at 14:28, stepharo  wrote:

>
> [ ... ]
>
>
> And this one I don't understand. A smooth, git / iceberg oriented
> transition over Monticello/Metacello is perfectly doable... As Dale
> explained. A nice Iceberg gui reworking / making git usable is perfect.
>
> But why make the transition so hard? You get Stef angry on a Sunday
> morning because he can't find things anymore... even if he is a strong
> proponent of the strategy he complains about ;)
>
>
> No my point was not that.
> My point is that it is important to pay attention and not to add more
> noise than necessary. Let us take the time and move alltogether.
>
> If you want to get somewhere with this story, you don't want to wait till
everything will be ready.
Transition will never start unless you force users to enter the minefield
and let them clear the mines for you. Step by step. Many will blow
themselves up, while some will manage to pass unhurt..
Because else, it will be always a minefield between you and the destination
of your journey :)


> Stef
>
>
> Thierry
>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/7/16 11:42 AM, Nicolas Passerini wrote:


2016-11-07 15:30 GMT+01:00 Thierry Goubier >:


Thierry, If I'm not mistaken, Esteban is referring to the fact
that in FileTree we are still using Monticello to do the load
of the packages and even when we are running metadataless, we
end creating fake meta data to simulate an mcz ... you and I
have had conversations about ways to eliminate this
"requirement" because it is meaningless in a git context ...


Yes, this I understood. I do believe that what I suggested at one
point (have the ability to compare versions with an
'isAncestorOf') would be very nice for that transition (work in
mcz as well as on git with/without metadata).


I would like to listen to your ideas about this topic, but I am not 
sure it is possible to achieve that compatibility. In fact we tried to 
do it for Iceberg and at some point we decided to abort it.


On one side, trying to re-create monticello sequential file numbers in 
git is simply not possible, at least in a reliable way. On the other 
side, loading the graph of package versions and dependencies is really 
slow for big repositories (such as pharo-core), once we removed that 
requirement Iceberg got like 100x faster.
I agree that the git-oriented tools should not go ot of their may to 
conform to the MC model .. as you say it just does not fit ... but many 
of the standard operations that are performed can be performed on both 
git and mcz repositories without forcing both of the models to share 
identical implementations ... in image tools should distinguish between 
mcz and git projects and dispatch the standard operations to the 
appropriate repository --- and this si the spot where the handling 
changes based upon the repository model ...


Dale

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/7/16 11:30 AM, Thierry Goubier wrote:

Hi Dale,

2016-11-07 12:03 GMT+01:00 Dale Henrichs 
>:




On 11/7/16 7:15 AM, Thierry Goubier wrote:



2016-11-07 11:05 GMT+01:00 Esteban Lorenzano >:



On 7 Nov 2016, at 10:03, Thierry Goubier
> wrote:

Hi Esteban,

I cut out the rest, because I agree with all your points,
except for...

2016-11-07 9:55 GMT+01:00 Esteban Lorenzano
>:

[ ... ]

Replacing Monticello with git goes in this direction:

[ ... ]


And this one I don't understand. A smooth, git / iceberg
oriented transition over Monticello/Metacello is perfectly
doable... As Dale explained. A nice Iceberg gui reworking /
making git usable is perfect.


Well… I disagree with this.
All my experience says the opposite: this is a convenience
usage that in the long way does not match (the thing that we
simulate mcz packages do not work… and makes things a lot
harder to maintain later).
Nico has worked a lot on this, maybe he has something to say.


I'd like to. Simulating mcz? That I don't get it.

Thierry, If I'm not mistaken, Esteban is referring to the fact
that in FileTree we are still using Monticello to do the load of
the packages and even when we are running metadataless, we end
creating fake meta data to simulate an mcz ... you and I have had
conversations about ways to eliminate this "requirement" because
it is meaningless in a git context ...


Yes, this I understood. I do believe that what I suggested at one 
point (have the ability to compare versions with an 'isAncestorOf') 
would be very nice for that transition (work in mcz as well as on git 
with/without metadata).
II think that the work that you did with gitfiletree was very 
influential in making git a realistic option for the Pharo community and 
I think that the choices you made were excellent, but I think that for a 
transition it is important that git be presented as itself more fully 
and expose some of the features that set git apart 
(project/package/class/method diffs; multi-package commits; etc.) ... 
but I also feel that Monticello does not need to be diluted --- the 
existing Monticello tools should remain in place for the forseeable 
future ...



With the work that Richard Sargent did on the
CypressReferenceImplementation, I would prefer to say that Cypress
can provide an Alternative to Monticello rather than replace it
... the CypressReferenceImplementation includes a package loader
so it isn't necessary to convert Filetree format on disk to Mcz
format in the image --- without all of the ancestry, "latest
version stuff" and package-cache the loading process becomes much,
much simpler...

I think that both Monticello and Cypress can live together in the
image ...


For me, MC is also the code / diff model behind: will Cypress rewrites 
all that too?
Well Cypress is not that much of a rewrite ... Cypress definitions are 
closely based upon the Monticello definition model... snapshots and 
loading based on comparing the snapshot of the repository against the 
snapshot of the image are also closely based on Monticello ... The 
differences are in the fact that Cypress packages do not have ancestry, 
author names or version numbers:

  - the ancestry and author is recorded and managed by git (or svn or hg)
  - there is only one version of a package in a fieltree repo, so there 
is no

 need to sort packages by version number to fine the "latest version"

So Cypress is more of a "take all of the really good parts of Monticello 
while dropping the bits that are handled better  by git" than it is a 
complete _rewrite_ ...



I have created a version of Metacello that uses Monticello OR
Cypress and I expect to eventually (in the next several months ---
it doesn't take that long, but I've got other things on my plate)
to have a version of Metacello that uses Monticello AND/OR Cypress
again I think that smooth transitions (that may take a long time)
are better supported in this fashion than to draw a line in the
sand and force the usage of one OR the other ...


As long as Cypress behaves as a MC repository and fits into the same 
API, I really don't see where is the difficulty. As we are saying now, 
adding a type of repository / emulating the MC overall API is no real 
difficulty in itself and isolates one from all the project management 
issues (because that means Metacello, ConfigurationOf and BaselineOf 
just keep working as usual).
There are api differences between MC and Cypress ... MC has ancestry and 

Re: [Pharo-users] About balkanisation

[Offray Vladimir Luna Cárdenas]

Hi,


On 07/11/16 02:50, Esteban Lorenzano wrote:
[...]

What I mean is that we can help any transition, but at the end there is no way 
of having a “nice, coexisting” ecosystem: we will have one OR the other, or 
something that does not works at all, but we will not have seamlessly one AND 
the other (which does not means people using monticello will be forced to use 
git tools or vice-versa, just that you will need to chose one… right now many 
(many for real) of our problems come from the attempt of keeping our git 
support behaving as regular monticello… and that way of doing has a limit. A 
limit I think we already passed.

[...]

That's clarifying. Thanks a lot Esteban. I will try to keep myself on 
the Monticello boat a little longer, until the filetree and Iceberg 
stuff become clearer to me and I can see how to use them in a way that 
doesn't interrupt the workflow I have now (as happens with Monticello 
and Fossil).



Anyway, if you can list what you think we will need for the transition, I will 
be very glad to see what we can do :)


Yes, Dale, your experience would be very appreciated.

Cheers,

Offray

Re: [Pharo-users] about balkanisation

[Nicolas Passerini]

2016-11-07 16:26 GMT+01:00 Thierry Goubier :

>
>> The problem I found is that in order to recreate sequential numbers, you
>> have to load all commits into the image.
>>
>
> Why? GitFileTree doesn't need to do that at all! Well, you know the code:
> it just ask git log to rebuild the parent / child relations for a package
> directory, and that is all... Then, like a mcz, the package isn't loaded
> into the image unless you select it in the GUI. So why did you need to load
> all the commits?
>
> Well, at the beginning, I was trying to read all the filetree metadata
> stored in the repository to build the versions as if it was mczs... and
> that was a really bad idea (slow parser for version files, hundred of files
> to scan, many files were even unreadable/broken by conflicts leftovers in
> the filetree repository).
>

Yes you are right, I expressed myself badly. You don't have to load "the
commits".
But, you still have to create an MCVersionInfo for each version of the
package in the repository.

In fact... you can create them, it will not kill you, but I think that this
structure is not so useful, because it is always faster to use log/revwalk
to ask about the relationship between two versions/commits.

Moreover, we do not want to think about packages too much, we prefer to
think in terms of a whole project, so the most interesting concept for us
is the commit and not the version. Therefore, when I build a history
(sometimes I do) I create a graph of commits and not a graph of versions.

Finally, this leads to that, even in the case you want to load a specific
version of a specific pacakge (which is not the normal case for Iceberg),
you would specify a commitish (+ a package name) and not a version name.

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

2016-11-07 16:13 GMT+01:00 Nicolas Passerini :

>
> I started creating version names using the unix date (the number of
> seconds since 1970), which allows me to provide version numbers without
> complex calculations and without breaking Monticello.
>
> Numbers are not nice but we do not use them any way, it is just to comply
> with Monticello requirements.
>

There is a human effect to them (I like to see the numbers increasing as I
add new versions, of course!) but, well, since Dale said working with .1
would work, so it is :)

Git short commit ID are only convenient for long-time git experts.


>
>>
>>> On one side, trying to re-create monticello sequential file numbers in
>>> git is simply not possible, at least in a reliable way. On the other side,
>>> loading the graph of package versions and dependencies is really slow for
>>> big repositories (such as pharo-core), once we removed that requirement
>>> Iceberg got like 100x faster.
>>>
>>
>> Yes, this is performance sensitive code. I spent a significant amount of
>> time trying to optimize the smalltalk part of that in gitfiletree a few
>> years ago... before I was shown that it could only scale to ~ 1000 commits
>> (with a repository that had more than 8000 different versions for a
>> package).
>>
>> Delegating everything to `git log` solved the issue. No code duplication!
>>
>> Overall, this is something that has worried me since the beginning of
>> libgit. Libgit is low level and pushes some of the processing into Pharo,
>> which is not the best tool to do high-speed processing of tree structures.
>> And then, instead of designing the best solution to our problem, you end up
>> trying to get the best design that doesn't hit a performance issue...
>>
>
> I am using git log extensively, turns out to be a very powerful tool.
> Libgit provides a very similar tool called revwalk (
> https://libgit2.github.com/libgit2/#HEAD/group/revwalk). So in each case
> Pharo does not have to do those performance sensitive computing.
>

Yes! Problem solved.


>
> The problem I found is that in order to recreate sequential numbers, you
> have to load all commits into the image.
>

Why? GitFileTree doesn't need to do that at all! Well, you know the code:
it just ask git log to rebuild the parent / child relations for a package
directory, and that is all... Then, like a mcz, the package isn't loaded
into the image unless you select it in the GUI. So why did you need to load
all the commits?

Well, at the beginning, I was trying to read all the filetree metadata
stored in the repository to build the versions as if it was mczs... and
that was a really bad idea (slow parser for version files, hundred of files
to scan, many files were even unreadable/broken by conflicts leftovers in
the filetree repository).

Thierry

Re: [Pharo-users] about balkanisation

[Nicolas Passerini]

2016-11-07 15:59 GMT+01:00 Thierry Goubier :

> 2016-11-07 15:42 GMT+01:00 Nicolas Passerini :
>
>>
>> 2016-11-07 15:30 GMT+01:00 Thierry Goubier :
>>
>>> Thierry, If I'm not mistaken, Esteban is referring to the fact that in
 FileTree we are still using Monticello to do the load of the packages and
 even when we are running metadataless, we end creating fake meta data to
 simulate an mcz ... you and I have had conversations about ways to
 eliminate this "requirement" because it is meaningless in a git context ...

>>>
>>> Yes, this I understood. I do believe that what I suggested at one point
>>> (have the ability to compare versions with an 'isAncestorOf') would be very
>>> nice for that transition (work in mcz as well as on git with/without
>>> metadata).
>>>
>>
>> I would like to listen to your ideas about this topic, but I am not sure
>> it is possible to achieve that compatibility. In fact we tried to do it for
>> Iceberg and at some point we decided to abort it.
>>
>
> I have an idea where such comparisons are done. I'd simply start by
> changing version numbers to the short commit ID, and see where it breaks ...
>

I started creating version names using the unix date (the number of seconds
since 1970), which allows me to provide version numbers without complex
calculations and without breaking Monticello.

Numbers are not nice but we do not use them any way, it is just to comply
with Monticello requirements.


>
>> On one side, trying to re-create monticello sequential file numbers in
>> git is simply not possible, at least in a reliable way. On the other side,
>> loading the graph of package versions and dependencies is really slow for
>> big repositories (such as pharo-core), once we removed that requirement
>> Iceberg got like 100x faster.
>>
>
> Yes, this is performance sensitive code. I spent a significant amount of
> time trying to optimize the smalltalk part of that in gitfiletree a few
> years ago... before I was shown that it could only scale to ~ 1000 commits
> (with a repository that had more than 8000 different versions for a
> package).
>
> Delegating everything to `git log` solved the issue. No code duplication!
>
> Overall, this is something that has worried me since the beginning of
> libgit. Libgit is low level and pushes some of the processing into Pharo,
> which is not the best tool to do high-speed processing of tree structures.
> And then, instead of designing the best solution to our problem, you end up
> trying to get the best design that doesn't hit a performance issue...
>

I am using git log extensively, turns out to be a very powerful tool.
Libgit provides a very similar tool called revwalk (
https://libgit2.github.com/libgit2/#HEAD/group/revwalk). So in each case
Pharo does not have to do those performance sensitive computing.

The problem I found is that in order to recreate sequential numbers, you
have to load all commits into the image.

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

2016-11-07 15:42 GMT+01:00 Nicolas Passerini :

>
> 2016-11-07 15:30 GMT+01:00 Thierry Goubier :
>
>> Thierry, If I'm not mistaken, Esteban is referring to the fact that in
>>> FileTree we are still using Monticello to do the load of the packages and
>>> even when we are running metadataless, we end creating fake meta data to
>>> simulate an mcz ... you and I have had conversations about ways to
>>> eliminate this "requirement" because it is meaningless in a git context ...
>>>
>>
>> Yes, this I understood. I do believe that what I suggested at one point
>> (have the ability to compare versions with an 'isAncestorOf') would be very
>> nice for that transition (work in mcz as well as on git with/without
>> metadata).
>>
>
> I would like to listen to your ideas about this topic, but I am not sure
> it is possible to achieve that compatibility. In fact we tried to do it for
> Iceberg and at some point we decided to abort it.
>

I have an idea where such comparisons are done. I'd simply start by
changing version numbers to the short commit ID, and see where it breaks ...


> On one side, trying to re-create monticello sequential file numbers in git
> is simply not possible, at least in a reliable way. On the other side,
> loading the graph of package versions and dependencies is really slow for
> big repositories (such as pharo-core), once we removed that requirement
> Iceberg got like 100x faster.
>

Yes, this is performance sensitive code. I spent a significant amount of
time trying to optimize the smalltalk part of that in gitfiletree a few
years ago... before I was shown that it could only scale to ~ 1000 commits
(with a repository that had more than 8000 different versions for a
package).

Delegating everything to `git log` solved the issue. No code duplication!

Overall, this is something that has worried me since the beginning of
libgit. Libgit is low level and pushes some of the processing into Pharo,
which is not the best tool to do high-speed processing of tree structures.
And then, instead of designing the best solution to our problem, you end up
trying to get the best design that doesn't hit a performance issue...

Thierry

Re: [Pharo-users] about balkanisation

[Nicolas Passerini]

2016-11-07 15:30 GMT+01:00 Thierry Goubier :

> Thierry, If I'm not mistaken, Esteban is referring to the fact that in
>> FileTree we are still using Monticello to do the load of the packages and
>> even when we are running metadataless, we end creating fake meta data to
>> simulate an mcz ... you and I have had conversations about ways to
>> eliminate this "requirement" because it is meaningless in a git context ...
>>
>
> Yes, this I understood. I do believe that what I suggested at one point
> (have the ability to compare versions with an 'isAncestorOf') would be very
> nice for that transition (work in mcz as well as on git with/without
> metadata).
>

I would like to listen to your ideas about this topic, but I am not sure it
is possible to achieve that compatibility. In fact we tried to do it for
Iceberg and at some point we decided to abort it.

On one side, trying to re-create monticello sequential file numbers in git
is simply not possible, at least in a reliable way. On the other side,
loading the graph of package versions and dependencies is really slow for
big repositories (such as pharo-core), once we removed that requirement
Iceberg got like 100x faster.

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

Hi Dale,

2016-11-07 12:03 GMT+01:00 Dale Henrichs :

>
>
> On 11/7/16 7:15 AM, Thierry Goubier wrote:
>
>
>
> 2016-11-07 11:05 GMT+01:00 Esteban Lorenzano :
>
>>
>> On 7 Nov 2016, at 10:03, Thierry Goubier 
>> wrote:
>>
>> Hi Esteban,
>>
>> I cut out the rest, because I agree with all your points, except for...
>>
>> 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano :
>>
>>> [ ... ]
>>>
>>> Replacing Monticello with git goes in this direction:
>>>
>>> [ ... ]
>>>
>>
>> And this one I don't understand. A smooth, git / iceberg oriented
>> transition over Monticello/Metacello is perfectly doable... As Dale
>> explained. A nice Iceberg gui reworking / making git usable is perfect.
>>
>>
>> Well… I disagree with this.
>> All my experience says the opposite: this is a convenience usage that in
>> the long way does not match (the thing that we simulate mcz packages do not
>> work… and makes things a lot harder to maintain later).
>> Nico has worked a lot on this, maybe he has something to say.
>>
>
> I'd like to. Simulating mcz? That I don't get it.
>
> Thierry, If I'm not mistaken, Esteban is referring to the fact that in
> FileTree we are still using Monticello to do the load of the packages and
> even when we are running metadataless, we end creating fake meta data to
> simulate an mcz ... you and I have had conversations about ways to
> eliminate this "requirement" because it is meaningless in a git context ...
>

Yes, this I understood. I do believe that what I suggested at one point
(have the ability to compare versions with an 'isAncestorOf') would be very
nice for that transition (work in mcz as well as on git with/without
metadata).


>
> With the work that Richard Sargent did on the
> CypressReferenceImplementation, I would prefer to say that Cypress can
> provide an Alternative to Monticello rather than replace it ... the
> CypressReferenceImplementation includes a package loader so it isn't
> necessary to convert Filetree format on disk to Mcz format in the image ---
> without all of the ancestry, "latest version stuff" and package-cache the
> loading process becomes much, much simpler...
>
> I think that both Monticello and Cypress can live together in the image ...
>

For me, MC is also the code / diff model behind: will Cypress rewrites all
that too?


>
> I have created a version of Metacello that uses Monticello OR Cypress and
> I expect to eventually (in the next several months --- it doesn't take that
> long, but I've got other things on my plate) to have a version of Metacello
> that uses Monticello AND/OR Cypress again I think that smooth transitions
> (that may take a long time) are better supported in this fashion than to
> draw a line in the sand and force the usage of one OR the other ...
>

As long as Cypress behaves as a MC repository and fits into the same API, I
really don't see where is the difficulty. As we are saying now, adding a
type of repository / emulating the MC overall API is no real difficulty in
itself and isolates one from all the project management issues (because
that means Metacello, ConfigurationOf and BaselineOf just keep working as
usual).

We need to get the MC repository API to evolve a bit, in part to handle the
"save multiple packages, do one commit without using package dependencies."
required now, and also to expose more of the repository organisation
(remotes, branches) for the GUI above. And remove some of the things saying
"I'm MC trying to do Metacello's job".

What is a bit annoying, really, is this talk of rewriting everything where
some of the pieces (the project browsing you're talkin about, for example)
is already there in the image, just not exposed.

I'm trying to code a little something for that... stay tuned for a
screenshot soon.

Thierry


>
> Dale
>

Re: [Pharo-users] about balkanisation

[stepharo]

[ ... ]


And this one I don't understand. A smooth, git / iceberg oriented 
transition over Monticello/Metacello is perfectly doable... As Dale 
explained. A nice Iceberg gui reworking / making git usable is perfect.


But why make the transition so hard? You get Stef angry on a Sunday 
morning because he can't find things anymore... even if he is a strong 
proponent of the strategy he complains about ;)


No my point was not that.
My point is that it is important to pay attention and not to add more 
noise than necessary. Let us take the time and move alltogether.


Stef



Thierry

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 7:36 AM, Esteban Lorenzano wrote:

On 7 Nov 2016, at 11:28, Dale Henrichs  wrote:



On 11/7/16 4:52 AM, Esteban Lorenzano wrote:

btw this is pharo-dev discussion, redirecting there.

Esteban


On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:

We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?

The main unifying tool is a Metacello Project Browser (or something like the 
tODE project list).

You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... 
but you know that already:) but once you load a Project into the image with the 
CatalogBrowser it sort of disappears ...

There needs to be a way to see the _projects_ are loaded in the image ... right 
now you can see the package loaded into the image, and you can see the dirty 
packages, but the package is at too low a level

 From the project browser you should be able to commit a project --- which 
saves all of the dirty packages in the project --- in one commit for a git 
project --- all of the dirty packages written in one operation for mcz packages 
...

This project browser can provide the same set of services for an mcz project 
(ConfigurationOf) or a filetree project (BaselineOf):
  - save
  - load-- this is a bit more complicated to explain (I tried at 
the Metacello Dr. talk, but more discussion is needed)
  - diff  -- project level diff over a collection of packages
  - commit log -- For ConfigurationOf, list the commit history of the 
Configuration.
For a BaselineOf list the commit log for the git 
repository

The workflow at the project level is not that different between Mcz and 
Filetree, so it is straightforward to work with …

this is what is provided by iceberg… it still needs some work, but this is 
precisely what is supposed to do :)
(and btw, this is why I disagree with Thierry some mails below).
Well, I don't think that Iceberg is doing package loads and I don't 
think that Iceberg will provide support for mcz repositories so I still 
think there is a need for this Metacello Project Browser ... the 
Metacello Project Browser would delegate to Iceberg for all of the 
services that it does provide.


The Metacello Project Browser would not be a purely git/github tool ... 
Metacello Projects are repository format neutral so svn, hg, etc. would 
be equally supported from the Metacello Project Browser ... the standard 
set of operations: save/load/diff/log are needed for all different 
repository types ...


I don't think it's a lot of work to implement the Metacello Project 
Browser tool and it is important that there be one place to look for and 
manage the projects loaded in image  this is the "unifying" bit ...



The unification comes because you can use one metaphor (project) to work with 
both Mcz and Filetree ... the underlying implementation will ultimately...

The next layer of unified tools is when you look at version history, for a 
method, you need to provide the ability to view the git commit history for the 
method (if stored in git) or the image history ... git commit hisotry can be 
provided at the project/package/class/method ... whereever possible the 
equivalent mcz/git service should be provided so that the two systems are on an 
even par …

also, this is supposed to be provided by iceberg.


The Monticello Browser and Iceberg GUI's don't go away, because it is often 
necessary to do work at the package level, but I think that putting focus on 
the project is the key ingredient to success for integrating git …

Iceberg is not package-oriented. It just show 
repositories/packages/classes/methods… this is a good way to do it and I do not 
thing anything is lost like this.
You need to take a second look at Iceberg :)
Well I am specifically referring to this issue[1] and this comment by 
Guille[2] and Nico[3]. If Iceberg isn't going to load packages, then you 
need a tool that will load a package ...


and as I say above this tool must work with ConfigurationOf and 
BaselineOf for svn, hg, etc. repositories ...


[1] https://github.com/npasserini/iceberg/issues/184
[2] https://github.com/npasserini/iceberg/issues/184#issuecomment-254139549
[3] https://github.com/npasserini/iceberg/issues/184#issuecomment-257865003



Since git repos are persistent on disk and will be shared ... it is important 
that there be a way for developers to easily access the git repos for projects 
that have been cloned locally but not yet loaded in the image itself ... I am 
really struggling with getting how important this point as this is the also a 
point that ties a Catalog Browser and Project Browser together

this is something to think… I do not get what catalog browser  can do here (but 
yes, a way to browse local repositories needs to be provided).
again in tODE, the Metacello Project Browser (aka project list) allows 
one to view projects that are 

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/7/16 7:15 AM, Thierry Goubier wrote:



2016-11-07 11:05 GMT+01:00 Esteban Lorenzano >:




On 7 Nov 2016, at 10:03, Thierry Goubier
> wrote:

Hi Esteban,

I cut out the rest, because I agree with all your points, except
for...

2016-11-07 9:55 GMT+01:00 Esteban Lorenzano >:

[ ... ]

Replacing Monticello with git goes in this direction:

[ ... ]


And this one I don't understand. A smooth, git / iceberg oriented
transition over Monticello/Metacello is perfectly doable... As
Dale explained. A nice Iceberg gui reworking / making git usable
is perfect.


Well… I disagree with this.
All my experience says the opposite: this is a convenience usage
that in the long way does not match (the thing that we simulate
mcz packages do not work… and makes things a lot harder to
maintain later).
Nico has worked a lot on this, maybe he has something to say.


I'd like to. Simulating mcz? That I don't get it.
Thierry, If I'm not mistaken, Esteban is referring to the fact that in 
FileTree we are still using Monticello to do the load of the packages 
and even when we are running metadataless, we end creating fake meta 
data to simulate an mcz ... you and I have had conversations about ways 
to eliminate this "requirement" because it is meaningless in a git 
context ...


With the work that Richard Sargent did on the 
CypressReferenceImplementation, I would prefer to say that Cypress can 
provide an Alternative to Monticello rather than replace it ... the 
CypressReferenceImplementation includes a package loader so it isn't 
necessary to convert Filetree format on disk to Mcz format in the image 
--- without all of the ancestry, "latest version stuff" and 
package-cache the loading process becomes much, much simpler...


I think that both Monticello and Cypress can live together in the image ...

I have created a version of Metacello that uses Monticello OR Cypress 
and I expect to eventually (in the next several months --- it doesn't 
take that long, but I've got other things on my plate) to have a version 
of Metacello that uses Monticello AND/OR Cypress again I think that 
smooth transitions (that may take a long time) are better supported in 
this fashion than to draw a line in the sand and force the usage of one 
OR the other ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 6:42 AM, Norbert Hartl wrote:

Am 07.11.2016 um 10:40 schrieb Dale Henrichs :



On 11/7/16 2:59 AM, Tudor Girba wrote:

Hi Dale,

I think I missed your mails. I would be interested in hearing your opinion. 
Let’s aim for a chat sometime next week. Would this work for you?

You're not the only one :) Yes it would ... Monday is a travel day so Tuesday 
or beyond would work for me …


Would it make sense to make that a group conversation?

I don't mind, but I do have to say that I am struggling in communicated 
some of the "simple concepts" ... My talk last Wednesday was my first 
attempt and I don't think I did a good job of communicating about some 
of the more complicated tasks that come up like: load specs, 
clone/lock/rehome, sharing local clones across multiple images, private 
image clones, etc. ...


My inclination is to have a focused conversation with Doru to help me 
express the key concepts ... then a more public discussion with another 
straw man where we put the ideas out again ...


Dale

Re: [Pharo-users] about balkanisation

[Dimitris Chloupis]

>
> Cuis basically delegates everything to git and use one file per package.
>
>

yes thats the direction I want to go with this, if possible kill any kind
of meta information and turn everything to Smalltalk code. Even fileout
contains meta data.


>
> He has a nice lib interface targetting both mercurial? and git; a kind of
> ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X
>

are you talking about this
https://github.com/janvrany/libgit2

his last commit was 4 years ago.

this is going the exact opposite direction once again tries to bring git
inside the pharo image.

Or are you talking about something else ?

"I don't understand how you can say that after so many years.

The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of
the language, the library and the environment (IDE). You can consider these
separately and many projects have taken one element out of it to another
context. However it is the combination that is magic.

Working (developing) command line or file based in Pharo/Smalltalk feels so
uncomfortable that it simply hurts. No browsers, no senders/implementors,
no workspaces, no inspector, no debugger, no spotter, no interaction, no ...

Anyway, this is my opinion and you are of course entitled to yours."

I try to refrain from criticising Pharo, because I don't want to decrease
the motivation of people contributing to Pharo which I consider critical to
the improvement of Pharo and secondly because my criticisms are largely
based on personal taste which I think would make for a very poor discussion
since personal taste cannot be debated.

The summary of my ideology is that there are only parts of Smalltalk I
really like and not the whole thing. I have several ideas about Pharo.
Whether some or all of those ideas will be proven bad or too difficult to
implement , time will tell.  Some of those ideas are

1) a component based environment similar to Delphi (one of the things  I
loved about Delphi). Basically Objects on steroids.

2) An enhancement of visual coding experience in Pharo.  Roassal could help
here.

3) The ability to use Emacs as an alternative code editor outside the box.
Shampoo has accomplished this goal, but I have not tested it yet.

4) Deep integration with both C++ and Python, this is more than a need
since I depend both on Python and C++, this idea is the closest to
materialisation and probably my most critical one

5) Modular image = This one I am lucky enough that is already a Pharo goal
and an ongoing project

6) A more powerful documentation system , Pillar could help here and the
inspector / gtspotter

7) Auto update in the background , not a high priority goal since I will be
using the Steam API that handles updates but it would be nice

8)  Fragmentation of the image format, this one will be a combination of
fuel (or custom format) and bootstrap

9) Removal of any mid ground between Smalltalk code and Git , this is the
idea I was talking early on

10) Integration with OS tools , like file browsers, web browsers , system
utilities etc

11) Replacement of Morphic with QT,  I already can do this at least in part
with my python bridge but for now its a low priority

12)  Management of user analytics, that will be specific to my games and
probably will utilise Steam's and Unreal's analytics for gathering
information about the user , obviously with the permission of the user,
most likely this will require minimum Pharo code

13) Unification of Browser, Workspace , GTInspector, GTDebugger and
GtSpotter under one tool

14) More strict evaluation of potential errors and user mistakes

and many more. All those ideas are mostly long term so it may be years if
not a decade before they materialise and probably will change along the
process to fit practical needs.

You could say that Ephestos most likely will turn into an alternative Pharo
Distribution like Cuis is for Squeak but with very different goals. Again
my goal is not to produce something for public consumption but merely an
image that follows more closely my personal taste.

Re: [Pharo-users] About balkanisation

[Esteban Lorenzano]

> On 7 Nov 2016, at 11:28, Dale Henrichs  
> wrote:
> 
> 
> 
> On 11/7/16 4:52 AM, Esteban Lorenzano wrote:
>> btw this is pharo-dev discussion, redirecting there.
>> 
>> Esteban
>> 
>>> On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:
>>> 
>>> We are developing Iceberg… and I know is not enough :)
>>> Which “unifying tools” are you referring ?
> The main unifying tool is a Metacello Project Browser (or something like the 
> tODE project list).
> 
> You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... 
> but you know that already:) but once you load a Project into the image with 
> the CatalogBrowser it sort of disappears ...
> 
> There needs to be a way to see the _projects_ are loaded in the image ... 
> right now you can see the package loaded into the image, and you can see the 
> dirty packages, but the package is at too low a level
> 
> From the project browser you should be able to commit a project --- which 
> saves all of the dirty packages in the project --- in one commit for a git 
> project --- all of the dirty packages written in one operation for mcz 
> packages ...
> 
> This project browser can provide the same set of services for an mcz project 
> (ConfigurationOf) or a filetree project (BaselineOf):
>  - save
>  - load-- this is a bit more complicated to explain (I tried at 
> the Metacello Dr. talk, but more discussion is needed)
>  - diff  -- project level diff over a collection of packages
>  - commit log -- For ConfigurationOf, list the commit history of the 
> Configuration.
>For a BaselineOf list the commit log for the git 
> repository
> 
> The workflow at the project level is not that different between Mcz and 
> Filetree, so it is straightforward to work with …

this is what is provided by iceberg… it still needs some work, but this is 
precisely what is supposed to do :)
(and btw, this is why I disagree with Thierry some mails below).

> 
> The unification comes because you can use one metaphor (project) to work with 
> both Mcz and Filetree ... the underlying implementation will ultimately...
> 
> The next layer of unified tools is when you look at version history, for a 
> method, you need to provide the ability to view the git commit history for 
> the method (if stored in git) or the image history ... git commit hisotry can 
> be provided at the project/package/class/method ... whereever possible the 
> equivalent mcz/git service should be provided so that the two systems are on 
> an even par …

also, this is supposed to be provided by iceberg. 

> 
> The Monticello Browser and Iceberg GUI's don't go away, because it is often 
> necessary to do work at the package level, but I think that putting focus on 
> the project is the key ingredient to success for integrating git …

Iceberg is not package-oriented. It just show 
repositories/packages/classes/methods… this is a good way to do it and I do not 
thing anything is lost like this.
You need to take a second look at Iceberg :) 

> 
> Since git repos are persistent on disk and will be shared ... it is important 
> that there be a way for developers to easily access the git repos for 
> projects that have been cloned locally but not yet loaded in the image itself 
> ... I am really struggling with getting how important this point as this is 
> the also a point that ties a Catalog Browser and Project Browser together

this is something to think… I do not get what catalog browser  can do here (but 
yes, a way to browse local repositories needs to be provided).

> 
> I've been using this approach for several years now and once you have the 
> tools and can see at a glance what's "going on in your image" it is fun to 
> work in a mixed environment ... all of this frustration that is bubbling on 
> the list is largely due to not having these missing tools and underlying 
> support --- I think …

I do not think we are so far from your vision. I think you did not get it 
Iceberg right… please, take a second look :)
now… is true that now everything you say is already done… but this is general 
orientation :)

Esteban

ps: all of this is *clearly* not pharo-users but pharo-dev discussion, let’s 
move there.

>>> 
>>> I have followed very close your TOdE development… in a moment I was 
>>> planning a migration of it for pure-pharo, just… lack of time as always and 
>>> then later we started iceberg.
> Yes, I have intended to do a port of tODE to Pharo, but of time is the killer 
> :)
>>> now, we are in the process of defining a process ;) who works for pharo and 
>>> is the moment to build the bridges we need, but in general I think that 
>>> staying "with a foot in two boats” can just work during a very short lapse 
>>> of time, after that, the stream continues going and if you do not finish 
>>> your jump into one of the boats you will be very fast in the water.
> Yes but the two boat environment will 

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 4:52 AM, Esteban Lorenzano wrote:

btw this is pharo-dev discussion, redirecting there.

Esteban


On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:

We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?
The main unifying tool is a Metacello Project Browser (or something like 
the tODE project list).


You have a nice tool with the CatalogBrowser (modulo BaselineOf support) 
... but you know that already:) but once you load a Project into the 
image with the CatalogBrowser it sort of disappears ...


There needs to be a way to see the _projects_ are loaded in the image 
... right now you can see the package loaded into the image, and you can 
see the dirty packages, but the package is at too low a level


From the project browser you should be able to commit a project --- 
which saves all of the dirty packages in the project --- in one commit 
for a git project --- all of the dirty packages written in one operation 
for mcz packages ...


This project browser can provide the same set of services for an mcz 
project (ConfigurationOf) or a filetree project (BaselineOf):

  - save
  - load-- this is a bit more complicated to explain (I 
tried at the Metacello Dr. talk, but more discussion is needed)

  - diff  -- project level diff over a collection of packages
  - commit log -- For ConfigurationOf, list the commit history of the 
Configuration.
For a BaselineOf list the commit log for 
the git repository


The workflow at the project level is not that different between Mcz and 
Filetree, so it is straightforward to work with ...


The unification comes because you can use one metaphor (project) to work 
with both Mcz and Filetree ... the underlying implementation will 
ultimately...


The next layer of unified tools is when you look at version history, for 
a method, you need to provide the ability to view the git commit history 
for the method (if stored in git) or the image history ... git commit 
hisotry can be provided at the project/package/class/method ... 
whereever possible the equivalent mcz/git service should be provided so 
that the two systems are on an even par ...


The Monticello Browser and Iceberg GUI's don't go away, because it is 
often necessary to do work at the package level, but I think that 
putting focus on the project is the key ingredient to success for 
integrating git ...


Since git repos are persistent on disk and will be shared ... it is 
important that there be a way for developers to easily access the git 
repos for projects that have been cloned locally but not yet loaded in 
the image itself ... I am really struggling with getting how important 
this point as this is the also a point that ties a Catalog Browser and 
Project Browser together


I've been using this approach for several years now and once you have 
the tools and can see at a glance what's "going on in your image" it is 
fun to work in a mixed environment ... all of this frustration that is 
bubbling on the list is largely due to not having these missing tools 
and underlying support --- I think ...


I have followed very close your TOdE development… in a moment I was planning a 
migration of it for pure-pharo, just… lack of time as always and then later we 
started iceberg.
Yes, I have intended to do a port of tODE to Pharo, but of time is the 
killer :)

now, we are in the process of defining a process ;) who works for pharo and is the 
moment to build the bridges we need, but in general I think that staying "with 
a foot in two boats” can just work during a very short lapse of time, after that, 
the stream continues going and if you do not finish your jump into one of the boats 
you will be very fast in the water.
Yes but the two boat environment will last years ... it has taken almost 
5 years for filetree to start to be used regularly ... and with the 
Metacello Project Browser approach the transition will not be nearly as 
painful, besides I think that the project-centric tools set is required 
when work with git


What I mean is that we can help any transition, but at the end there is no way 
of having a “nice, coexisting” ecosystem: we will have one OR the other, or 
something that does not works at all, but we will not have seamlessly one AND 
the other (which does not means people using monticello will be forced to use 
git tools or vice-versa, just that you will need to chose one… right now many 
(many for real) of our problems come from the attempt of keeping our git 
support behaving as regular monticello…
As I say, I think that monticello/filetree can be abstracted away at the 
Metacello Project Browser level ... a commit of dirty packages writes 
all the dirty packages for the project in the appropriate repository ... 
BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take 
a whole lot of code to smoothly handle both projects --- as I've said, 

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

2016-11-07 11:05 GMT+01:00 Esteban Lorenzano :

>
> On 7 Nov 2016, at 10:03, Thierry Goubier 
> wrote:
>
> Hi Esteban,
>
> I cut out the rest, because I agree with all your points, except for...
>
> 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano :
>
>> [ ... ]
>>
>> Replacing Monticello with git goes in this direction:
>>
>> [ ... ]
>>
>
> And this one I don't understand. A smooth, git / iceberg oriented
> transition over Monticello/Metacello is perfectly doable... As Dale
> explained. A nice Iceberg gui reworking / making git usable is perfect.
>
>
> Well… I disagree with this.
> All my experience says the opposite: this is a convenience usage that in
> the long way does not match (the thing that we simulate mcz packages do not
> work… and makes things a lot harder to maintain later).
> Nico has worked a lot on this, maybe he has something to say.
>

I'd like to. Simulating mcz? That I don't get it.

I've seen many things done in Pharo that have a strong NIH tag attached to
them. So I allways take the 'I reimplement everything because I know
better' with a grain of salt.

Nico has a huge task.


>
>
> But why make the transition so hard? You get Stef angry on a Sunday
> morning because he can't find things anymore... even if he is a strong
> proponent of the strategy he complains about ;)
>
>
> Stef was angry because he needs to clone, pull, commit, push and make a PR
> to collaborate… and because that process is not correctly
> documented/tooled.
> Sadly, this will not change… it will always be like that.
> What we can do is easy the task creating the tools… but that will need to
> be there.
>

Agreed. It's about time, by the way. Pharo lost some usability on the
SLICES/mcz front over the years, and its painfull when teaching Pharo.

Thierry

Re: [Pharo-users] about balkanisation

[Sven Van Caekenberghe]

> On 7 Nov 2016, at 10:43, Dimitris Chloupis  wrote:
> 
> Its clear that I want to live outside the image.
> 
> Its clear that others want to live inside the image.
> 
> Its clear that I am a tiny minority , if not the only one. 

I don't understand how you can say that after so many years.

The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the 
language, the library and the environment (IDE). You can consider these 
separately and many projects have taken one element out of it to another 
context. However it is the combination that is magic.

Working (developing) command line or file based in Pharo/Smalltalk feels so 
uncomfortable that it simply hurts. No browsers, no senders/implementors, no 
workspaces, no inspector, no debugger, no spotter, no interaction, no ...

Anyway, this is my opinion and you are of course entitled to yours.

Sven
 

Re: [Pharo-users] about balkanisation

[Esteban Lorenzano]

> On 7 Nov 2016, at 10:03, Thierry Goubier  wrote:
> 
> Hi Esteban,
> 
> I cut out the rest, because I agree with all your points, except for...
> 
> 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano  >:
> [ ... ]
> 
> Replacing Monticello with git goes in this direction:
> 
> [ ... ]
> 
> And this one I don't understand. A smooth, git / iceberg oriented transition 
> over Monticello/Metacello is perfectly doable... As Dale explained. A nice 
> Iceberg gui reworking / making git usable is perfect.

Well… I disagree with this. 
All my experience says the opposite: this is a convenience usage that in the 
long way does not match (the thing that we simulate mcz packages do not work… 
and makes things a lot harder to maintain later). 
Nico has worked a lot on this, maybe he has something to say.

> 
> But why make the transition so hard? You get Stef angry on a Sunday morning 
> because he can't find things anymore... even if he is a strong proponent of 
> the strategy he complains about ;)

Stef was angry because he needs to clone, pull, commit, push and make a PR to 
collaborate… and because that process is not correctly documented/tooled. 
Sadly, this will not change… it will always be like that.
What we can do is easy the task creating the tools… but that will need to be 
there. 

Esteban

> 
> Thierry

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

2016-11-07 10:43 GMT+01:00 Dimitris Chloupis :

> "
> Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me
> (Jan's format is even more conflict-oriented than Filetree metadata, but it
> is a design goal). Cuis git repository is a mess to me; very hard to build
> a coherent 'rebuild a new Cuis here' process on it like I routinely do on
> Pharo."
>
>
> Cuis I downloaded it, does not seem to have such a tool, talking about
> auto export of code.
>

Cuis basically delegates everything to git and use one file per package.


>
> Jon Vrany which I found here
>
> https://github.com/janvrany?tab=overview=2015-12-01=
> 2015-12-31=✓
>
> appears that he has not done any Smalltalk coding for more than a year and
> I could not find one repo that has such tool.
>

He has a nice lib interface targetting both mercurial? and git; a kind of
ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X


>
> Just to make it clear what I am proposing here is not just a replacement
> for filetree but I complete bypass of Monticello. I have been a frequent
> visitor of the pharo mailing lists for more than 5 years not I never head
> of such a thing. It is also the first time I mention this idea as well. I
> had in my mind for so long but it has been a low priority because filetree
> worked without any issues other than browsing the code in code editor and
> online Github.
>
> "I've seen over the years many, many attempts at replacing the filetree
> format. I used to contest and debate, now I just let them go and die a few
> months later. Because none of the alternatives are clearly superior, and it
> is not worth the effort to reimplement."
>
> Well if by dying you mean none else but me will use it, most certainly you
> are correct. But all my projects are foremost personal I never make
> something for public consumption other than offering a helping hand with
> Pharo documentation.
>

I mean really dying: like in even the creator isn't using it anymore.

You really need good code to hold something alone over the years, something
that keeps working across Pharo versions as they evolve with minimum
changes. Trust me on that!

One strategy is to base yourself on stable core components of Pharo. Some
stuff in Pharo changes a lot, some has been very stable since Pharo 3 (or
upgraded very nicely while maintaining the same API). You may be better off
reimplementing stuff changing too fast / or too buggy in their current
incarnation, just to decouple yourself: when you go for a self/alone
project, your goals do not align with the main image.


>
> I am perfectly ok with the fact that people do not use my projects.
>
> And foremost its not as if a tool that would bypass monticello and
> filetree and gitfiletree and iceberg has any chance to be used when for
> months now the mailing list has been talking about Iceberg.
>
> Its clear that I want to live outside the image.
>
> Its clear that others want to live inside the image.
>
> Its clear that I am a tiny minority , if not the only one.
>

I think you're less radical than you believe :)

Thierry

Re: [Pharo-users] about balkanisation

[Esteban Lorenzano]

> On 7 Nov 2016, at 10:42, Norbert Hartl  wrote:
> 
>> 
>> Am 07.11.2016 um 10:28 schrieb Esteban Lorenzano :
>> 
>> 
>>> On 7 Nov 2016, at 10:17, Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 7 Nov 2016, at 10:13, Thierry Goubier  wrote:
 
 I've seen over the years many, many attempts at replacing the filetree 
 format. I used to contest and debate, now I just let them go and die a few 
 months later. Because none of the alternatives are clearly superior, and 
 it is not worth the effort to reimplement.
 
 (I quite enjoy reading filetree-based code on github: it is layed out like 
 my browser, neat and clean. Moreover, all my code involve multiple 
 classes, which means switching between files anyway. Given that reading 
 those !! was never a pleasure, even when I started using Smalltalk in 1991)
>>> 
>>> Indeed. I agree 100%.
>> 
>> I was even thinking on propose someone (a student project, maybe?) to do an 
>> embeddable browser people could put in their README.md, to browse sources 
>> “as in Pharo” :) 
>> a Seaside app to do that would not be hard, I think… and can be hosted on 
>> PharoCloud (or whatever you want). 
>> 
> I fully agree to your previous mail (the long one) but want to add that it is 
> not only the number of things to maintain that plays an important role in 
> taming complexity. You can count the complexity of each project into that 
> calculation. And proposing something using seaside is not an approach 
> according to this rule ;)

I know :)
I’m not saying I will do it… or maintain it… just that it would be cool and 
fairly easy :P

Esteban

> 
> Norbert

Re: [Pharo-users] about balkanisation

[Dimitris Chloupis]

"
Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me
(Jan's format is even more conflict-oriented than Filetree metadata, but it
is a design goal). Cuis git repository is a mess to me; very hard to build
a coherent 'rebuild a new Cuis here' process on it like I routinely do on
Pharo."


Cuis I downloaded it, does not seem to have such a tool, talking about auto
export of code.

Jon Vrany which I found here

https://github.com/janvrany?tab=overview=2015-12-01=2015-12-31=✓

appears that he has not done any Smalltalk coding for more than a year and
I could not find one repo that has such tool.

Just to make it clear what I am proposing here is not just a replacement
for filetree but I complete bypass of Monticello. I have been a frequent
visitor of the pharo mailing lists for more than 5 years not I never head
of such a thing. It is also the first time I mention this idea as well. I
had in my mind for so long but it has been a low priority because filetree
worked without any issues other than browsing the code in code editor and
online Github.

"I've seen over the years many, many attempts at replacing the filetree
format. I used to contest and debate, now I just let them go and die a few
months later. Because none of the alternatives are clearly superior, and it
is not worth the effort to reimplement."

Well if by dying you mean none else but me will use it, most certainly you
are correct. But all my projects are foremost personal I never make
something for public consumption other than offering a helping hand with
Pharo documentation.

I am perfectly ok with the fact that people do not use my projects.

And foremost its not as if a tool that would bypass monticello and filetree
and gitfiletree and iceberg has any chance to be used when for months now
the mailing list has been talking about Iceberg.

Its clear that I want to live outside the image.

Its clear that others want to live inside the image.

Its clear that I am a tiny minority , if not the only one.


>

Re: [Pharo-users] About balkanisation

[Norbert Hartl]

> Am 07.11.2016 um 10:40 schrieb Dale Henrichs 
> :
> 
> 
> 
> On 11/7/16 2:59 AM, Tudor Girba wrote:
>> Hi Dale,
>> 
>> I think I missed your mails. I would be interested in hearing your opinion. 
>> Let’s aim for a chat sometime next week. Would this work for you?
> You're not the only one :) Yes it would ... Monday is a travel day so Tuesday 
> or beyond would work for me …
> 
Would it make sense to make that a group conversation?

Norbert

Re: [Pharo-users] about balkanisation

[Norbert Hartl]

> Am 07.11.2016 um 10:28 schrieb Esteban Lorenzano :
> 
> 
>> On 7 Nov 2016, at 10:17, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 7 Nov 2016, at 10:13, Thierry Goubier  wrote:
>>> 
>>> I've seen over the years many, many attempts at replacing the filetree 
>>> format. I used to contest and debate, now I just let them go and die a few 
>>> months later. Because none of the alternatives are clearly superior, and it 
>>> is not worth the effort to reimplement.
>>> 
>>> (I quite enjoy reading filetree-based code on github: it is layed out like 
>>> my browser, neat and clean. Moreover, all my code involve multiple classes, 
>>> which means switching between files anyway. Given that reading those !! was 
>>> never a pleasure, even when I started using Smalltalk in 1991)
>> 
>> Indeed. I agree 100%.
> 
> I was even thinking on propose someone (a student project, maybe?) to do an 
> embeddable browser people could put in their README.md, to browse sources “as 
> in Pharo” :) 
> a Seaside app to do that would not be hard, I think… and can be hosted on 
> PharoCloud (or whatever you want). 
> 
I fully agree to your previous mail (the long one) but want to add that it is 
not only the number of things to maintain that plays an important role in 
taming complexity. You can count the complexity of each project into that 
calculation. And proposing something using seaside is not an approach according 
to this rule ;)

Norbert

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 2:59 AM, Tudor Girba wrote:

Hi Dale,

I think I missed your mails. I would be interested in hearing your opinion. 
Let’s aim for a chat sometime next week. Would this work for you?
You're not the only one :) Yes it would ... Monday is a travel day so 
Tuesday or beyond would work for me ...


Dale

Re: [Pharo-users] about balkanisation

[Esteban Lorenzano]

> On 7 Nov 2016, at 10:17, Sven Van Caekenberghe  wrote:
> 
> 
>> On 7 Nov 2016, at 10:13, Thierry Goubier  wrote:
>> 
>> I've seen over the years many, many attempts at replacing the filetree 
>> format. I used to contest and debate, now I just let them go and die a few 
>> months later. Because none of the alternatives are clearly superior, and it 
>> is not worth the effort to reimplement.
>> 
>> (I quite enjoy reading filetree-based code on github: it is layed out like 
>> my browser, neat and clean. Moreover, all my code involve multiple classes, 
>> which means switching between files anyway. Given that reading those !! was 
>> never a pleasure, even when I started using Smalltalk in 1991)
> 
> Indeed. I agree 100%.

I was even thinking on propose someone (a student project, maybe?) to do an 
embeddable browser people could put in their README.md, to browse sources “as 
in Pharo” :) 
a Seaside app to do that would not be hard, I think… and can be hosted on 
PharoCloud (or whatever you want). 

Esteban

Re: [Pharo-users] about balkanisation

[Sven Van Caekenberghe]

> On 7 Nov 2016, at 10:13, Thierry Goubier  wrote:
> 
> I've seen over the years many, many attempts at replacing the filetree 
> format. I used to contest and debate, now I just let them go and die a few 
> months later. Because none of the alternatives are clearly superior, and it 
> is not worth the effort to reimplement.
> 
> (I quite enjoy reading filetree-based code on github: it is layed out like my 
> browser, neat and clean. Moreover, all my code involve multiple classes, 
> which means switching between files anyway. Given that reading those !! was 
> never a pleasure, even when I started using Smalltalk in 1991)

Indeed. I agree 100%.

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

Hi Kilon,

2016-11-07 9:57 GMT+01:00 Dimitris Chloupis :

>
> Git requirements is basically non existent, it mainly works with text
> files and with less support for binary files. Pharo does not need anything
> but text files to be ready for Git. We had text files since forever with
> fileouts and became more convenient with filetree.
>

Agreed (of course!).


>
> You are also wrong about Seaside kind of projects. Its actually ironic to
> talk about complex projects when Git itself was made by the creator of
> Linux and the Linux kernel developers have been using it for the Linux
> kernel for ages. Actually one of the reasons why Linux created Git was
> because he was disappointed how slow and cumbersome SVN was with big and
> complex projects and to this day Git's speed and ability to handle enormous
> complexity with ease is what makes it first choice for many projects and
> probably the most popular VCS.
>
> Aa such not only SmalltalkHub has been an extremely poor alternativre to
> Github , its claims like yours that keep the Pharo community using tools
> that extremely limited , buggy and close to nowhere as Smalltalky enough. I
> am not talking about here just for Smalltalkhub but also Monticello. That
> weird Gui thing , that is just weird and sometimes is also weird.
>
> If however here we talk personal taste, if people want to recreate tools
> that exist outside the pharo image because they prefer to stay inside the
> pharo image , I am not against that but then I never criticised personal
> taste. Its a free world after all. Tools like Iceberg are more than
> welcomed as long as I can easily remove them from my image.
>
> Personally the only toolset I will be implementing will be a tool to
> completely bypass monticello and filetree and instead mark classes for
> export and code will be exported most likely in a fileout format
> automatically each time I hit accept in the browser.
>
>
Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me
(Jan's format is even more conflict-oriented than Filetree metadata, but it
is a design goal). Cuis git repository is a mess to me; very hard to build
a coherent 'rebuild a new Cuis here' process on it like I routinely do on
Pharo.

I've seen over the years many, many attempts at replacing the filetree
format. I used to contest and debate, now I just let them go and die a few
months later. Because none of the alternatives are clearly superior, and it
is not worth the effort to reimplement.

(I quite enjoy reading filetree-based code on github: it is layed out like
my browser, neat and clean. Moreover, all my code involve multiple classes,
which means switching between files anyway. Given that reading those !! was
never a pleasure, even when I started using Smalltalk in 1991)

Regards,

Thierry

Re: [Pharo-users] about balkanisation

[Thierry Goubier]

Hi Esteban,

I cut out the rest, because I agree with all your points, except for...

2016-11-07 9:55 GMT+01:00 Esteban Lorenzano :

> [ ... ]
>
> Replacing Monticello with git goes in this direction:
>
> [ ... ]
>

And this one I don't understand. A smooth, git / iceberg oriented
transition over Monticello/Metacello is perfectly doable... As Dale
explained. A nice Iceberg gui reworking / making git usable is perfect.

But why make the transition so hard? You get Stef angry on a Sunday morning
because he can't find things anymore... even if he is a strong proponent of
the strategy he complains about ;)

Thierry

Re: [Pharo-users] about balkanisation

[Dimitris Chloupis]

On Sun, Nov 6, 2016 at 6:22 PM Stephan Eggermont  wrote:

> Kilon wrote:
> > If you really want to embrace Github , kill Smalltalkhub
>
> We are not close to doing that. We'll need
> Monticello support indefinitely, and at least a few years two-way. And
> that assumes we automatically migrate all open projects.
>
> First we need good workflows that also work for complex projects. That
> includes cross-platform projects like Seaside
>
> Stephan
>

I remember the first time I asked about Pharo and Git maybe 3 years ago ,
you are one of the first to tell me exactly what you saying now, Pharo is
not close to be ready for Git.

My first assumption was that you were wrong but respecting your experience
as a Smalltalk coder I decided to not fully embrace Git and instead
continue to have my project both in Git and in StHub. Few months in this
experiment and I confirmed what I suspecting all along that you were wrong.

Git requirements is basically non existent, it mainly works with text files
and with less support for binary files. Pharo does not need anything but
text files to be ready for Git. We had text files since forever with
fileouts and became more convenient with filetree.

You are also wrong about Seaside kind of projects. Its actually ironic to
talk about complex projects when Git itself was made by the creator of
Linux and the Linux kernel developers have been using it for the Linux
kernel for ages. Actually one of the reasons why Linux created Git was
because he was disappointed how slow and cumbersome SVN was with big and
complex projects and to this day Git's speed and ability to handle enormous
complexity with ease is what makes it first choice for many projects and
probably the most popular VCS.

Aa such not only SmalltalkHub has been an extremely poor alternativre to
Github , its claims like yours that keep the Pharo community using tools
that extremely limited , buggy and close to nowhere as Smalltalky enough. I
am not talking about here just for Smalltalkhub but also Monticello. That
weird Gui thing , that is just weird and sometimes is also weird.

If however here we talk personal taste, if people want to recreate tools
that exist outside the pharo image because they prefer to stay inside the
pharo image , I am not against that but then I never criticised personal
taste. Its a free world after all. Tools like Iceberg are more than
welcomed as long as I can easily remove them from my image.

Personally the only toolset I will be implementing will be a tool to
completely bypass monticello and filetree and instead mark classes for
export and code will be exported most likely in a fileout format
automatically each time I hit accept in the browser.

Re: [Pharo-users] about balkanisation

[Esteban Lorenzano]

Hi,

If anyone *ever* thought we are moving to git because is the new stuff, I need 
to clarify several things: 

1) you don’t know me :) 
2) git is not new-cool stuff since a couple of years so is not that we are 
jumping into anything fancy shiny new (we should be trying to use docker as 
monticello repositories if that would be the case). 

Now, let’s talk for real: suppose for a second that you are a software 
architect (whatever that means) that has in your shoulders the responsibility 
of drive forward this amazing project called is Pharo. 
Pharo is a HUGE project with a lot of composants all of them moving. Many times 
because people introduces changes, others because changes affects others (this 
is not cool, but happens a lot) and some other simply time passes and world 
changes around us, which also makes our vision of things change. 
Now, in this context, as a software architect you do an analysis of risk and 
you get that Pharo has a lot of them, I will quote just a couple:

- As a “moving target”, maintainability is the first big issue: the accidental 
complexity of the system tends constantly to increase (sometimes, as with some 
version, at speeds you wouldn’t believe it). Also, incorporating new tools 
means new things to maintain, constantly. 
- We do not have enough resources. No idea if we will ever get enough 
resources, but we do not have enough people to keep maintaining everything and 
in addition iterate to evolve Pharo. Of course we benefit of been a large 
community with many people contributing but that is an advantage but also a 
risk.
- People pushes their own agendas. This is perfectly ok, but that means the 
effort is not measurable nor dirigible :)
- tools are OLD. Many of them (including monticello) were built for a world who 
do not exists any more: software projects are *different* now: bigger, 
multi-platform, multi-language, N-tier, etc., etc. etc.
- … (I can continue all day detecting risks)

Now, always as a software architect, you detected an important amount of risks 
that can make fail your project, and then you have to take decisions to 
mitigate this risks. 
One possibility is stop moving. Freezing that part will add a lot of stability 
to the system… just we will using a relic, and the world will continue 
changing… others have followed this path. Pharo vision is (and has always been) 
other… we need, we want  to continue moving. So this solution cannot be taken. 
Other solution is to hire more people. Of course, no money and no money means 
no more people. Another solution that cannot be taken. 

So we arrive to a third solution: Reduce the amount of things that needs to be 
maintained and are “non essential”,  so we can concentrate in developing what 
is actually our thing: we do Pharo. 

Replacing Monticello with git goes in this direction:

- it allows us to stop maintaining sthub (or any other pharo-based repository). 
Let’s face it: we will NEVER develop a tool as good as 
github/gitlab/bitbucket/the next thing. Why? Because it is NOT OUT BUSINESS. 
They have developers there, who’s only work is to do such tool.
- but also: it allow developing sotfware projects in ways monticello don’t: 
multi language, external sources, etc.
- but also: it allow CI without us needing to maintain jenkins (another thing 
that we will able to not maintain anymore… I spent far too much time there and 
I spent 1% of the time that Christophe spent there, for example). 
- but also: it reduces the level of “alieness” that newcomers experiments when 
they arrive to Pharo (let’s face it: most people arrives to Pharo already 
knowing other languages and most of them are expecting a file-based way of 
sharing… many of them are expecting git, in fact). 

In other order of things: 
- I spent last week replacing a backend made in amber with a backend made in 
seaside just to remove amber from the equation: so something we need to 
maintain is pharo-exclusive (this is “architecture 101”: systems complexity 
increases exponentially for each language you add). 
- I spent last 3 months aligning the PharoVM with the CogVM, removing what was 
a “de facto” fork, just to reduce the amount of maintenance effort we need to 
put there. And to join efforts with Eliot and all others (because joining a 
larger team and collaborate with them is also a way to incorporate more people 
into our own VM).
- I spent months developing UFFI to remove NativeBoost from the equation with 
exactly the same purpose: reduce the amount of things we need to maintain.

So, as Pharo architect, Pharo fireman, stabilisation faery, whatever you want 
to call me, it is my responsibility to be sure Pharo will continue moving 
forward, and this is my answer. 
But not just me. I work on RMoD team at INRIA. The research team purpose is 
precisely to support “software evolution”. This means I have the luck of work 
with some of the best people in the world to ask for this kind of questions. 
And there is also the Pharo board, 

Re: [Pharo-users] About balkanisation

[Esteban Lorenzano]

btw this is pharo-dev discussion, redirecting there.

Esteban

> On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:
> 
> We are developing Iceberg… and I know is not enough :)
> Which “unifying tools” are you referring ?
> 
> I have followed very close your TOdE development… in a moment I was planning 
> a migration of it for pure-pharo, just… lack of time as always and then later 
> we started iceberg.
> now, we are in the process of defining a process ;) who works for pharo and 
> is the moment to build the bridges we need, but in general I think that 
> staying "with a foot in two boats” can just work during a very short lapse of 
> time, after that, the stream continues going and if you do not finish your 
> jump into one of the boats you will be very fast in the water. 
> 
> What I mean is that we can help any transition, but at the end there is no 
> way of having a “nice, coexisting” ecosystem: we will have one OR the other, 
> or something that does not works at all, but we will not have seamlessly one 
> AND the other (which does not means people using monticello will be forced to 
> use git tools or vice-versa, just that you will need to chose one… right now 
> many (many for real) of our problems come from the attempt of keeping our git 
> support behaving as regular monticello… and that way of doing has a limit. A 
> limit I think we already passed. 
> 
> Anyway, if you can list what you think we will need for the transition, I 
> will be very glad to see what we can do :)
> 
> Esteban
> 
>> On 7 Nov 2016, at 06:30, Dale Henrichs  
>> wrote:
>> 
>> 
>> 
>> On 11/6/16 1:12 PM, Tudor Girba wrote:
>>> Hi Stef,
>>> 
>>> I think that you are raising a valid point, and I actually agree with it.
>>> 
>>> But I think there is another side of the coin as well.
>>> 
>>> I think that right now we are in between worlds and this is not quite 
>>> beneficial. Switching to GitHub is a significant effort, and treating it as 
>>> business as usual will not work. That is why I think it is so important 
>>> that we committed to the move for Pharo 7 and that we invest in the 
>>> infrastructure. But, this will not be enough either if we do not get people 
>>> to exercise it as soon as possible.
>> Doru, there are also holes in the tool set that are not being addressed ... 
>> there are a number of critical tools that need to be created and I don't see 
>> anyone working on them 
>> 
>> I went through this transition 5 years ago with my tool set and with the 
>> proper set of tools approach the difficult transition will be a bit easier 
>> ...
>> 
>> As it stands Pharo is standing with one foot in two boats ... there are the 
>> old Monticello tools and the new Git/Filetree tools and what is needed is a 
>> tool or two that can unify to both tool sets so that the transition between 
>> the two can be seamless ... these two sets of tools are not complicated and 
>> there working implementations that can be adapted to Pharo or used as a 
>> fairly detailed guide ...
>> 
>> The confusion and frustration that I see now is not a surprise to me ... I 
>> wrote" the emails" at the beginning of this year because I saw that Pharo 
>> was finally reaching a critical point in its move to integrate git into the 
>> mainstream development environment and I knew that these types of issues 
>> were going to come up where Monticello and Git were going to create friction 
>> --- friction that can be reduced by creating some simple "unifying tools" ...
>> 
>> I want to help, I have tried to help and I am still willing to help, but I 
>> cannot write the tools for Pharo ...
>> 
>> Dale
>> 
> 

Re: [Pharo-users] About balkanisation

[Esteban Lorenzano]

We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?

I have followed very close your TOdE development… in a moment I was planning a 
migration of it for pure-pharo, just… lack of time as always and then later we 
started iceberg.
now, we are in the process of defining a process ;) who works for pharo and is 
the moment to build the bridges we need, but in general I think that staying 
"with a foot in two boats” can just work during a very short lapse of time, 
after that, the stream continues going and if you do not finish your jump into 
one of the boats you will be very fast in the water. 

What I mean is that we can help any transition, but at the end there is no way 
of having a “nice, coexisting” ecosystem: we will have one OR the other, or 
something that does not works at all, but we will not have seamlessly one AND 
the other (which does not means people using monticello will be forced to use 
git tools or vice-versa, just that you will need to chose one… right now many 
(many for real) of our problems come from the attempt of keeping our git 
support behaving as regular monticello… and that way of doing has a limit. A 
limit I think we already passed. 

Anyway, if you can list what you think we will need for the transition, I will 
be very glad to see what we can do :)

Esteban

> On 7 Nov 2016, at 06:30, Dale Henrichs  
> wrote:
> 
> 
> 
> On 11/6/16 1:12 PM, Tudor Girba wrote:
>> Hi Stef,
>> 
>> I think that you are raising a valid point, and I actually agree with it.
>> 
>> But I think there is another side of the coin as well.
>> 
>> I think that right now we are in between worlds and this is not quite 
>> beneficial. Switching to GitHub is a significant effort, and treating it as 
>> business as usual will not work. That is why I think it is so important that 
>> we committed to the move for Pharo 7 and that we invest in the 
>> infrastructure. But, this will not be enough either if we do not get people 
>> to exercise it as soon as possible.
> Doru, there are also holes in the tool set that are not being addressed ... 
> there are a number of critical tools that need to be created and I don't see 
> anyone working on them 
> 
> I went through this transition 5 years ago with my tool set and with the 
> proper set of tools approach the difficult transition will be a bit easier ...
> 
> As it stands Pharo is standing with one foot in two boats ... there are the 
> old Monticello tools and the new Git/Filetree tools and what is needed is a 
> tool or two that can unify to both tool sets so that the transition between 
> the two can be seamless ... these two sets of tools are not complicated and 
> there working implementations that can be adapted to Pharo or used as a 
> fairly detailed guide ...
> 
> The confusion and frustration that I see now is not a surprise to me ... I 
> wrote" the emails" at the beginning of this year because I saw that Pharo was 
> finally reaching a critical point in its move to integrate git into the 
> mainstream development environment and I knew that these types of issues were 
> going to come up where Monticello and Git were going to create friction --- 
> friction that can be reduced by creating some simple "unifying tools" ...
> 
> I want to help, I have tried to help and I am still willing to help, but I 
> cannot write the tools for Pharo ...
> 
> Dale
> 

Re: [Pharo-users] about balkanisation

[p...@highoctane.be]

Mcz repos are useful.

STH storage works nicely, that's more the frontend which si bitrotting.

I actually have a local FTP based thing on my Synology and it is neat and
needs no time to work.

Did you ever look into Zinc and see there is also a server there for that?

Now, GitHub is better for sharing as there is the *critical mass* there.
And the tooling is very good.

And we can stuff a lot of other things than mcz in it (and with Git LFS
https://git-lfs.github.com/ we could even stuff images and mcz in there
right away. This thing is next in line for inclusion in
https://github.com/Pharophile/ExternalTools

In pvt chats on Slack, there is this tension between moving forward and
stabilizing stuff. I hope that with boostrap, we'll be able to have a
stable core and LTS assemblies.

Reinventing the wheel is fun. But it better has to be a better wheel.

Let's alway thing about our "normal"
https://www.youtube.com/watch?v=FvmTSpJU-Xc

We are at risk of boiling ourselves, in whatever plane we are.

I like the progress and I hate to have to adapt. But once past the curve,
life is actually better. Lots.

Phil




On Mon, Nov 7, 2016 at 5:29 AM, Igor Stasenko  wrote:

>
>
> On 6 November 2016 at 17:21, Stephan Eggermont  wrote:
>
>> Kilon wrote:
>> > If you really want to embrace Github , kill Smalltalkhub
>>
>> We are not close to doing that. We'll need
>> Monticello support indefinitely, and at least a few years two-way. And
>> that assumes we automatically migrate all open projects.
>>
>> First we need good workflows that also work for complex projects. That
>> includes cross-platform projects like Seaside
>>
>>
> Oh, come on! Throw away everything you had.. and start using something new
> and trendy, rinse and repeat. Profit!
> :)
>
>
>> Stephan
>>
>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-users] About balkanisation

[Tudor Girba]

Hi Dale,

I think I missed your mails. I would be interested in hearing your opinion. 
Let’s aim for a chat sometime next week. Would this work for you?

Cheers,
Doru


> On Nov 7, 2016, at 6:30 AM, Dale Henrichs  
> wrote:
> 
> 
> 
> On 11/6/16 1:12 PM, Tudor Girba wrote:
>> Hi Stef,
>> 
>> I think that you are raising a valid point, and I actually agree with it.
>> 
>> But I think there is another side of the coin as well.
>> 
>> I think that right now we are in between worlds and this is not quite 
>> beneficial. Switching to GitHub is a significant effort, and treating it as 
>> business as usual will not work. That is why I think it is so important that 
>> we committed to the move for Pharo 7 and that we invest in the 
>> infrastructure. But, this will not be enough either if we do not get people 
>> to exercise it as soon as possible.
> Doru, there are also holes in the tool set that are not being addressed ... 
> there are a number of critical tools that need to be created and I don't see 
> anyone working on them 
> 
> I went through this transition 5 years ago with my tool set and with the 
> proper set of tools approach the difficult transition will be a bit easier ...
> 
> As it stands Pharo is standing with one foot in two boats ... there are the 
> old Monticello tools and the new Git/Filetree tools and what is needed is a 
> tool or two that can unify to both tool sets so that the transition between 
> the two can be seamless ... these two sets of tools are not complicated and 
> there working implementations that can be adapted to Pharo or used as a 
> fairly detailed guide ...
> 
> The confusion and frustration that I see now is not a surprise to me ... I 
> wrote" the emails" at the beginning of this year because I saw that Pharo was 
> finally reaching a critical point in its move to integrate git into the 
> mainstream development environment and I knew that these types of issues were 
> going to come up where Monticello and Git were going to create friction --- 
> friction that can be reduced by creating some simple "unifying tools" ...
> 
> I want to help, I have tried to help and I am still willing to help, but I 
> cannot write the tools for Pharo ...
> 
> Dale
> 

--
www.tudorgirba.com
www.feenk.com

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/6/16 1:12 PM, Tudor Girba wrote:

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.
Doru, there are also holes in the tool set that are not being addressed 
... there are a number of critical tools that need to be created and I 
don't see anyone working on them 


I went through this transition 5 years ago with my tool set and with the 
proper set of tools approach the difficult transition will be a bit 
easier ...


As it stands Pharo is standing with one foot in two boats ... there are 
the old Monticello tools and the new Git/Filetree tools and what is 
needed is a tool or two that can unify to both tool sets so that the 
transition between the two can be seamless ... these two sets of tools 
are not complicated and there working implementations that can be 
adapted to Pharo or used as a fairly detailed guide ...


The confusion and frustration that I see now is not a surprise to me ... 
I wrote" the emails" at the beginning of this year because I saw that 
Pharo was finally reaching a critical point in its move to integrate git 
into the mainstream development environment and I knew that these types 
of issues were going to come up where Monticello and Git were going to 
create friction --- friction that can be reduced by creating some simple 
"unifying tools" ...


I want to help, I have tried to help and I am still willing to help, but 
I cannot write the tools for Pharo ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/6/16 9:05 AM, stepharo wrote:

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(
Stef, I have been working with git/monticello projects for about 5 years 
now and have been using a "mixed system" during that entire time ... My 
message has been consistent that in order to make a smooth transition 
that you need some specific tools, now the fact that you guys are _not_ 
building those tools has been concerning me for some time now ... I sent 
mails at the beginning of this year a) describing the tools to the best 
of my ability and b) offering to help ... it seems that you are somehow 
blaming git/github for this problem ... and as I come to this discussion 
late others are blaming smalltalkhub ...


I don't think it is necessary to move everything to github, as I said, I 
have been using a "mixed system" for 5 years ... and I think that the 
problem lies in the lack of the proper tools ... of course your problems 
with Bloc may be actually totally unrelated to packages, but it is clear 
to me that you are frustrated with the environment ... and that is a 
tools problem!


I can and want to help.

I have had good discussions with the Pharo team, but I am afraid that I 
am not able to get my ... to me ... simple points across ... and it is 
frustrating to me that I am not able to successfully communicate the 
simple solutions that I see ...


I will repeat that Pharo is missing some very critical tools that I 
consider to be absolutely required (in some form) to be able to be 
successful ... the required tools do not take a phd to implement, they 
are very straightforward and simple ... perhaps they are not sexy and 
complicated so noone is interested, but they are required ...


If you want to have a conversation about this I am willing ... now it 
happens that I am in Buenos Aires (soon to be Tucuman) so this week is 
not convenient for me to talk ...


If you don't want to talk to me then look at the series of messages that 
I wrote last winter/spring to this mailing list (or pharo dev) where I 
described what I think you guys are missing ... and then ask me 
questions ...


Dale

Re: [Pharo-users] about balkanisation

[Igor Stasenko]

On 6 November 2016 at 17:21, Stephan Eggermont  wrote:

> Kilon wrote:
> > If you really want to embrace Github , kill Smalltalkhub
>
> We are not close to doing that. We'll need
> Monticello support indefinitely, and at least a few years two-way. And
> that assumes we automatically migrate all open projects.
>
> First we need good workflows that also work for complex projects. That
> includes cross-platform projects like Seaside
>
>
Oh, come on! Throw away everything you had.. and start using something new
and trendy, rinse and repeat. Profit!
:)


> Stephan
>
>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] About balkanisation

[Offray Vladimir Luna Cárdenas]

And for us, without Git :-).

Offray


On 06/11/16 13:27, Dimitris Chloupis wrote:

I agree Pharo works great for me with Git apart from the file tree issue.
On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna Cárdenas 
> wrote:


Hi,

This thread derived on using GitHub, the transitions to it, the
mismatch
between the Smalltalk code model and the files code model. I would
like
to offer another view.

Pharo is working pretty well here. We have just finished our seventh
edition of the Data Week workshop+hackathon. This time we explored the
fossil DCVS and make some templates with mustache to
export/publish some
data visualizations. The infrastructure we have now doesn't get in our
way, installing the software with Catalog, updating with Monticello,
syncing changes while the workshop is happening, working with teapot,
tealight and the mustache binding all that went pretty smooth. The
supporting documentation for these tools was of great help.

Nicolas is making a good job in making the transition to Git/GitHub
smooth, but at the same time he is having a critical perspective
on git
and its workflow (which is not the best for every community, case or
project) and I think that's healthy, so we don't need to make Pharo
conform to git.

So I just want to add that there are other places and people
(mostly not
developers), here in Colombia, South America, that really appreciate
what the Pharo ecosystem, in its current form, is offering: its fluid,
uniform, connected, self contained, and powerful. It is a breath of
fresh air in the current overcomplicated technology. I just hope that
the migration and evolution preserve and maximize that. Keeping the
equilibrium between fast feedback, change, diversity, balkanisation,
visibility and hyper trendy is difficult, but hopefully the core
experience that Pharo is providing, will guide such equilibrium, and
continue to serve its several communities around the world.

Cheers,

Offray


On 06/11/16 07:05, stepharo wrote:
> Hi
>
> I would like that you think a bit about our community and that there
> is a value in using common tools
>
> to share and develop common libraries. Because to me it feels
like we
> are getting balkanize.
>
>
> It may look super cool and be hyper trendy to use github
(because like
> that you can say that you use latest hyper cool
>
> features), but I would like to ask especially people building
> libraries to pay attention that it is important
>
> that other people can contribute back easily and that there is
an easy
> way to load/contribute.
>
> Today I experienced Bloc
>
> - I cannot load code and I cannot contribute.
>
> - I saw mdl with a mixture between smalltalkhub and github
(sounds
> super hyper cool) and I saw paul not being able to contribute :(
>
>
> Yes you can say that monticello sucks yes it is terrible yes we all
> fell like Cobol programmers but at the end of the day.
>
> Yes the herb is always greener elsewhere. Yes yes yes. Let us take
> some facts.
>
> We managed pharo and moose with it over the last 8 years
successfully
> and Pharo and moose are not 5 packages together from
>
> what I can see. So pay attention about the decision you take.
>
> Now we will provide git support (this is 8 months that nicolas is
> exclusively working/thinking/dreaming
>
> about that) and that we are doing experiments (Guille is
managing the
> bootstrap in github).
>
> Now when everybody will have its own little project lost on
github (I
> do not count the amount of time I do not find pillar on github
because
> I forget
>
> that it is called pillar-markup), what will we do.
>
> So we need an infrastructure to handle this and christophe is
working
> on this.
>
> I think that you should consider the accidental complexity as
> something that we can minimise by using patterns and common
practices.
>
> Now you can think that I'm an idiot and that I have no vision (be my
> guest) but we should pay attention because we are a small community.
>
> Stef
>
>
>
>
>

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

The commit messages, say nothing about the commits

On Sun, 6 Nov 2016 at 17:47, Sven Van Caekenberghe  wrote:

>
> > On 6 Nov 2016, at 16:27, Dimitris Chloupis 
> wrote:
> >
> > A biggy one is the pharo repo of the pharo image on github. Its a mess.
> >
> > https://github.com/pharo-project/pharo-core/commits/6.0
> >
> > seriously, Github makes us visible , this does not look good at all.
>
> why not ? how is this different from a multi file commit in any other
> language ?
>
>
>

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

I agree Pharo works great for me with Git apart from the file tree issue.
On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
> This thread derived on using GitHub, the transitions to it, the mismatch
> between the Smalltalk code model and the files code model. I would like
> to offer another view.
>
> Pharo is working pretty well here. We have just finished our seventh
> edition of the Data Week workshop+hackathon. This time we explored the
> fossil DCVS and make some templates with mustache to export/publish some
> data visualizations. The infrastructure we have now doesn't get in our
> way, installing the software with Catalog, updating with Monticello,
> syncing changes while the workshop is happening, working with teapot,
> tealight and the mustache binding all that went pretty smooth. The
> supporting documentation for these tools was of great help.
>
> Nicolas is making a good job in making the transition to Git/GitHub
> smooth, but at the same time he is having a critical perspective on git
> and its workflow (which is not the best for every community, case or
> project) and I think that's healthy, so we don't need to make Pharo
> conform to git.
>
> So I just want to add that there are other places and people (mostly not
> developers), here in Colombia, South America, that really appreciate
> what the Pharo ecosystem, in its current form, is offering: its fluid,
> uniform, connected, self contained, and powerful. It is a breath of
> fresh air in the current overcomplicated technology. I just hope that
> the migration and evolution preserve and maximize that. Keeping the
> equilibrium between fast feedback, change, diversity, balkanisation,
> visibility and hyper trendy is difficult, but hopefully the core
> experience that Pharo is providing, will guide such equilibrium, and
> continue to serve its several communities around the world.
>
> Cheers,
>
> Offray
>
>
> On 06/11/16 07:05, stepharo wrote:
> > Hi
> >
> > I would like that you think a bit about our community and that there
> > is a value in using common tools
> >
> > to share and develop common libraries. Because to me it feels like we
> > are getting balkanize.
> >
> >
> > It may look super cool and be hyper trendy to use github (because like
> > that you can say that you use latest hyper cool
> >
> > features), but I would like to ask especially people building
> > libraries to pay attention that it is important
> >
> > that other people can contribute back easily and that there is an easy
> > way to load/contribute.
> >
> > Today I experienced Bloc
> >
> > - I cannot load code and I cannot contribute.
> >
> > - I saw mdl with a mixture between smalltalkhub and github (sounds
> > super hyper cool) and I saw paul not being able to contribute :(
> >
> >
> > Yes you can say that monticello sucks yes it is terrible yes we all
> > fell like Cobol programmers but at the end of the day.
> >
> > Yes the herb is always greener elsewhere. Yes yes yes. Let us take
> > some facts.
> >
> > We managed pharo and moose with it over the last 8 years successfully
> > and Pharo and moose are not 5 packages together from
> >
> > what I can see. So pay attention about the decision you take.
> >
> > Now we will provide git support (this is 8 months that nicolas is
> > exclusively working/thinking/dreaming
> >
> > about that) and that we are doing experiments (Guille is managing the
> > bootstrap in github).
> >
> > Now when everybody will have its own little project lost on github (I
> > do not count the amount of time I do not find pillar on github because
> > I forget
> >
> > that it is called pillar-markup), what will we do.
> >
> > So we need an infrastructure to handle this and christophe is working
> > on this.
> >
> > I think that you should consider the accidental complexity as
> > something that we can minimise by using patterns and common practices.
> >
> > Now you can think that I'm an idiot and that I have no vision (be my
> > guest) but we should pay attention because we are a small community.
> >
> > Stef
> >
> >
> >
> >
> >
>
>
>

Re: [Pharo-users] About balkanisation

[Offray Vladimir Luna Cárdenas]

Hi,

This thread derived on using GitHub, the transitions to it, the mismatch 
between the Smalltalk code model and the files code model. I would like 
to offer another view.


Pharo is working pretty well here. We have just finished our seventh 
edition of the Data Week workshop+hackathon. This time we explored the 
fossil DCVS and make some templates with mustache to export/publish some 
data visualizations. The infrastructure we have now doesn't get in our 
way, installing the software with Catalog, updating with Monticello, 
syncing changes while the workshop is happening, working with teapot, 
tealight and the mustache binding all that went pretty smooth. The 
supporting documentation for these tools was of great help.


Nicolas is making a good job in making the transition to Git/GitHub 
smooth, but at the same time he is having a critical perspective on git 
and its workflow (which is not the best for every community, case or 
project) and I think that's healthy, so we don't need to make Pharo 
conform to git.


So I just want to add that there are other places and people (mostly not 
developers), here in Colombia, South America, that really appreciate 
what the Pharo ecosystem, in its current form, is offering: its fluid, 
uniform, connected, self contained, and powerful. It is a breath of 
fresh air in the current overcomplicated technology. I just hope that 
the migration and evolution preserve and maximize that. Keeping the 
equilibrium between fast feedback, change, diversity, balkanisation, 
visibility and hyper trendy is difficult, but hopefully the core 
experience that Pharo is providing, will guide such equilibrium, and 
continue to serve its several communities around the world.


Cheers,

Offray


On 06/11/16 07:05, stepharo wrote:

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all 
fell like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take 
some facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I 
do not count the amount of time I do not find pillar on github because 
I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working 
on this.


I think that you should consider the accidental complexity as 
something that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef

Re: [Pharo-users] about balkanisation

[stepharo]

Le 6/11/16 à 17:21, Stephan Eggermont a écrit :

Kilon wrote:

If you really want to embrace Github , kill Smalltalkhub

We are not close to doing that. We'll need
Monticello support indefinitely, and at least a few years two-way. And that 
assumes we automatically migrate all open projects.


We decided that iceberg will support one way from MC -> github but not 
the inverse because we do not have the ressources.


First we need good workflows that also work for complex projects. That includes 
cross-platform projects like Seaside
We should be able to manage Pharo with the external projects composing 
it. Moose Seaside should be working too.


So yes this is why guille spent some time building cases and evaluate 
solutions (submodules vs subtrees vs under one umbrella)

with pull requests between subprojects and the rest



Stephan

Re: [Pharo-users] About balkanisation

[stepharo]

Le 6/11/16 à 17:12, Tudor Girba a écrit :

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.


Yes this what we decided.

To give an example. When the first version of Iceberg was announced, I started 
to use it for a couple of projects. I stumbled across problems that prevented 
me from working for several weeks. I could have easily switched to 
SmalltalkHub, but I did not. I connected with Nicolas and we worked through 
those problems. Btw, Nicolas is doing a wonderful job, and people should not 
take this for granted. He tends to be shy, so if you see him around, please 
give him a hug and let him know that we count on him. Or better yet, use 
Iceberg for your projects and send him your feedback :).


Yes people should try but should pay attention for libraries.

I am sure that there are more problems ahead, and the only way to go through 
them is committing to go through them. This will push us back for a while, but 
I really believe in the promise once we get on the other side. I actually think 
that GitHub is not really a good match for Pharo from a conceptual point of 
view (the mismatch between what it offers and what we need is quite large), but 
it is an engineering decision that makes perfect sense for the future. So, yes, 
we should take GitHub with a grain of salt, and make it a goal to not change 
much our concept of what makes sense for Pharo. For example, we should not give 
up on having to resort to the file system. That is why it is so important to 
make Iceberg (this is not for you Stef because I know you know it, but for 
others :)).

And I certainly agree that we should look for sane patterns, but as it goes 
with patterns, they emerge out of practice.

I think we should aim for limiting the time of being in between the two worlds. 
It will not be pleasant, and we can only do it if we stick together and go 
through it as soon as possible.


This why I mentioned that we should pay attention to create different 
versions




Cheers,
Doru





On Nov 6, 2016, at 1:05 PM, stepharo  wrote:

Hi

I would like that you think a bit about our community and that there is a value 
in using common tools

to share and develop common libraries. Because to me it feels like we are 
getting balkanize.


It may look super cool and be hyper trendy to use github (because like that you 
can say that you use latest hyper cool

features), but I would like to ask especially people building libraries to pay 
attention that it is important

that other people can contribute back easily and that there is an easy way to 
load/contribute.

Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds super 
hyper cool) and I saw paul not being able to contribute :(


Yes you can say that monticello sucks yes it is terrible yes we all fell like 
Cobol programmers but at the end of the day.

Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.

We managed pharo and moose with it over the last 8 years successfully and Pharo 
and moose are not 5 packages together from

what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is exclusively 
working/thinking/dreaming

about that) and that we are doing experiments (Guille is managing the bootstrap 
in github).

Now when everybody will have its own little project lost on github (I do not 
count the amount of time I do not find pillar on github because I forget

that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working on this.

I think that you should consider the accidental complexity as something that we 
can minimise by using patterns and common practices.

Now you can think that I'm an idiot and that I have no vision (be my guest) but 
we should pay attention because we are a small community.

Stef





--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-users] about balkanisation

[Stephan Eggermont]

Kilon wrote:
> If you really want to embrace Github , kill Smalltalkhub

We are not close to doing that. We'll need 
Monticello support indefinitely, and at least a few years two-way. And that 
assumes we automatically migrate all open projects. 

First we need good workflows that also work for complex projects. That includes 
cross-platform projects like Seaside

Stephan

Re: [Pharo-users] About balkanisation

[Tudor Girba]

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.

To give an example. When the first version of Iceberg was announced, I started 
to use it for a couple of projects. I stumbled across problems that prevented 
me from working for several weeks. I could have easily switched to 
SmalltalkHub, but I did not. I connected with Nicolas and we worked through 
those problems. Btw, Nicolas is doing a wonderful job, and people should not 
take this for granted. He tends to be shy, so if you see him around, please 
give him a hug and let him know that we count on him. Or better yet, use 
Iceberg for your projects and send him your feedback :).

I am sure that there are more problems ahead, and the only way to go through 
them is committing to go through them. This will push us back for a while, but 
I really believe in the promise once we get on the other side. I actually think 
that GitHub is not really a good match for Pharo from a conceptual point of 
view (the mismatch between what it offers and what we need is quite large), but 
it is an engineering decision that makes perfect sense for the future. So, yes, 
we should take GitHub with a grain of salt, and make it a goal to not change 
much our concept of what makes sense for Pharo. For example, we should not give 
up on having to resort to the file system. That is why it is so important to 
make Iceberg (this is not for you Stef because I know you know it, but for 
others :)).

And I certainly agree that we should look for sane patterns, but as it goes 
with patterns, they emerge out of practice.

I think we should aim for limiting the time of being in between the two worlds. 
It will not be pleasant, and we can only do it if we stick together and go 
through it as soon as possible.

Cheers,
Doru




> On Nov 6, 2016, at 1:05 PM, stepharo  wrote:
> 
> Hi
> 
> I would like that you think a bit about our community and that there is a 
> value in using common tools
> 
> to share and develop common libraries. Because to me it feels like we are 
> getting balkanize.
> 
> 
> It may look super cool and be hyper trendy to use github (because like that 
> you can say that you use latest hyper cool
> 
> features), but I would like to ask especially people building libraries to 
> pay attention that it is important
> 
> that other people can contribute back easily and that there is an easy way to 
> load/contribute.
> 
> Today I experienced Bloc
> 
>- I cannot load code and I cannot contribute.
> 
>- I saw mdl with a mixture between smalltalkhub and github (sounds super 
> hyper cool) and I saw paul not being able to contribute :(
> 
> 
> Yes you can say that monticello sucks yes it is terrible yes we all fell like 
> Cobol programmers but at the end of the day.
> 
> Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
> 
> We managed pharo and moose with it over the last 8 years successfully and 
> Pharo and moose are not 5 packages together from
> 
> what I can see. So pay attention about the decision you take.
> 
> Now we will provide git support (this is 8 months that nicolas is exclusively 
> working/thinking/dreaming
> 
> about that) and that we are doing experiments (Guille is managing the 
> bootstrap in github).
> 
> Now when everybody will have its own little project lost on github (I do not 
> count the amount of time I do not find pillar on github because I forget
> 
> that it is called pillar-markup), what will we do.
> 
> So we need an infrastructure to handle this and christophe is working on this.
> 
> I think that you should consider the accidental complexity as something that 
> we can minimise by using patterns and common practices.
> 
> Now you can think that I'm an idiot and that I have no vision (be my guest) 
> but we should pay attention because we are a small community.
> 
> Stef
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-users] About balkanisation

[Sven Van Caekenberghe]

> On 6 Nov 2016, at 16:27, Dimitris Chloupis  wrote:
> 
> A biggy one is the pharo repo of the pharo image on github. Its a mess.
> 
> https://github.com/pharo-project/pharo-core/commits/6.0
> 
> seriously, Github makes us visible , this does not look good at all.

why not ? how is this different from a multi file commit in any other language ?

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

If you really want to embrace Github , kill Smalltalkhub.

Smalltalkhub should have been dead years ago. Its unmaintained anyway apart
from when it crashes and Esteban fixes. Smalltalkhub has been a constant
state from crashes since 2011 when I joined Pharo community.

Give people a month to move their projects in github and then kill it. At
worst give only read access the same way squeakers made the old
squeaksource read only.

Another thing that must be fixed is the file format chosen for git, the
idea to fragment source code to a billion diffirent source code files each
one containing a method or class definition is problematic both for viewing
those files offline and online. There is very little chance that if I give
a link to my github repo to an outsider to take a look at my code that he
will have the patience to navigate 10 files to read the code for 10
methods. Even the class comment is a separate file. I don't even have the
patience to do that.

Make an organisation for people to join, those are made inside github we
have one for the books we have none for the community , this way we can
gain easier visibility of source code and it will also make easier for
people to contribute to third party code.

Move the meta repos of Pharo to Github and remove "meta" from the name.
Instead name them Pharo Packages Catalog as we do inside the image. One
repo for all versions of Pharo. Branches can be used to separate versions.

Add to Playground the ability to paste code directly to Gist. This is a low
priority one but its a nice touch.

A biggy one is the pharo repo of the pharo image on github. Its a mess.

https://github.com/pharo-project/pharo-core/commits/6.0

seriously, Github makes us visible , this does not look good at all.

If you do all the above you will have reduced the pain of working with Git
by 80%.

On Sun, Nov 6, 2016 at 4:37 PM stepharo  wrote:

> Dimitris
>
> better reread what I wrote because you missed it.
>
> My point is let us minimize the mess and act in a concerted way. Do you
> think that we would pay 9 months of dev + esteban that will started to
> push there too
>
> and base all our dev on it if we would not believe that moving to git is
> stupid!
>
> Can you read what I write?
>
> Stef
>
>
> Le 6/11/16 à 13:05, stepharo a écrit :
> > Hi
> >
> > I would like that you think a bit about our community and that there
> > is a value in using common tools
> >
> > to share and develop common libraries. Because to me it feels like we
> > are getting balkanize.
> >
> >
> > It may look super cool and be hyper trendy to use github (because like
> > that you can say that you use latest hyper cool
> >
> > features), but I would like to ask especially people building
> > libraries to pay attention that it is important
> >
> > that other people can contribute back easily and that there is an easy
> > way to load/contribute.
> >
> > Today I experienced Bloc
> >
> > - I cannot load code and I cannot contribute.
> >
> > - I saw mdl with a mixture between smalltalkhub and github (sounds
> > super hyper cool) and I saw paul not being able to contribute :(
> >
> >
> > Yes you can say that monticello sucks yes it is terrible yes we all
> > fell like Cobol programmers but at the end of the day.
> >
> > Yes the herb is always greener elsewhere. Yes yes yes. Let us take
> > some facts.
> >
> > We managed pharo and moose with it over the last 8 years successfully
> > and Pharo and moose are not 5 packages together from
> >
> > what I can see. So pay attention about the decision you take.
> >
> > Now we will provide git support (this is 8 months that nicolas is
> > exclusively working/thinking/dreaming
> >
> > about that) and that we are doing experiments (Guille is managing the
> > bootstrap in github).
> >
> > Now when everybody will have its own little project lost on github (I
> > do not count the amount of time I do not find pillar on github because
> > I forget
> >
> > that it is called pillar-markup), what will we do.
> >
> > So we need an infrastructure to handle this and christophe is working
> > on this.
> >
> > I think that you should consider the accidental complexity as
> > something that we can minimise by using patterns and common practices.
> >
> > Now you can think that I'm an idiot and that I have no vision (be my
> > guest) but we should pay attention because we are a small community.
> >
> > Stef
> >
> >
> >
> >
> >
>
>
>

Re: [Pharo-users] About balkanisation

[stepharo]

Dimitris

better reread what I wrote because you missed it.

My point is let us minimize the mess and act in a concerted way. Do you 
think that we would pay 9 months of dev + esteban that will started to 
push there too


and base all our dev on it if we would not believe that moving to git is 
stupid!


Can you read what I write?

Stef


Le 6/11/16 à 13:05, stepharo a écrit :

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all 
fell like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take 
some facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I 
do not count the amount of time I do not find pillar on github because 
I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working 
on this.


I think that you should consider the accidental complexity as 
something that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

> It may look super cool and be hyper trendy to use github (because like
> that you can say that you use latest hyper cool
>
> features), but I would like to ask especially people building libraries
> to pay attention that it is important
>
> that other people can contribute back easily and that there is an easy
> way to load/contribute.
>
>
>
 Indeed Git and Github are hypercool and trendy but the important question
here is why.

Why C++ is so popular, why Java is so popular, why Javascript is so
popular, Why python is so popular. When you ask why you understand that
being hyper cool, its not a thing, its not something you can glance over

its a practical need

we needed a language that is super fast with ability to handle complex
code, C++
we needed a language that is focused on enterprise development , Java
we needed a language to make web developent, Javascript
we needed a language to simplify C/C++/Java and C# without losing
libraries, Python
we needed a superfast decentralized versions control systems for both code
and other assets , Git
we needed a place to host online open source projects with git , Github
we needed the perfect language , the perfect libraries a tool to end all
tools , Nothing

each one of those hypercools excel in what you are doing, in many cases
they are more than one, not because they are easy but because they are
powerful. To go back to old alternatives would be like going back to caves
because you have hard time opening the front door of your house.

You may choose to go back to the cave but do not expect people to follow
you.

You preach people not to leave the comforts of the nest because its safe
and it easy, but in the end I find that as wasted potential.

The question I am asking myself everyday how far can Pharo go with taking
advantage of modern technology, how far Pharo can go if it gains access to
the same exact resources as all other programming languages ? What would it
mean for the average Pharo developer to be able to use not just web dev
libraries but any library, any tool , any programming language , any time ?

If you can answer these questions then you know why embracing git and
github is the right choice even if it pains you, even if makes you lose
sleep sometimes or even if you find it hard.

Just because Smalltalk is an island, Pharo does not need to be one.

Afterall  Pharo is not Smalltalk, or so we claim

Its time to put our money where our mouths are.

[Pharo-users] About balkanisation

[stepharo]

Hi

I would like that you think a bit about our community and that there is 
a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building libraries 
to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all fell 
like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take some 
facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I do 
not count the amount of time I do not find pillar on github because I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working on 
this.


I think that you should consider the accidental complexity as something 
that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef