Smalltalk › Pharo › Pharo Smalltalk Users

How to contribute to Calypso when it relies on pharo-core editors?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Tim Mackinnon

How to contribute to Calypso when it relies on pharo-core editors?

Hi - so in trying to improve the sendersof/implementors of - I thought I had nailed it (and got working what I had done in Pharo 6 for Pharo 7) - but when I loaded my commit into a fresh image I realised that none of the (minor) changes I had made to Calypso had been committed.

This is actually quite confusing - and its take me a while to realise that Calypso is a separate project and so when I picked commit on Pharo - this won’t pick up any of the changes in Calypso…. Arrrgggg

So now I’m guessing that I have to follow the same steps that I followed for loading a pharo repo - for Calypso?

But then if I do this - and I propose some fixes to Calypso - how can it work, as it relies on some changes to older pharo core editors that its inserting from?

My changes without Calypso will work (they did in V6) - but then how can someone test those in V7 as Calypso is then the default variable.

I’m in a bit of a twist - how can I proceed?

I’d really like to help improve the situation - as its bugged me for years that its a pain looking stuff up quickly (requiring you to highlight just the right stuff for very obvious things)

Tim

Tim Mackinnon

Re: How to contribute to Calypso when it relies on pharo-core editors?

Thinking about this more - why doesn’t Calypso appear in iceberg as a separate project alongside iceberg and Pharo?

That’s what’s confusing? And how did it get loaded from it’s git project without it appearing?

Which all makes me think there might need to be an iceberg setting - show/hide system projects so they don’t get in the way of your own projects.

But then if you accidentally save a method in a system class - how are we going to spit it and know?

I hate getting burned when you thought you were on a roll

Tim

Sent from my iPhone

> On 20 Jun 2018, at 02:26, Tim Mackinnon <[hidden email]> wrote:
>
> Hi - so in trying to improve the sendersof/implementors of - I thought I had nailed it (and got working what I had done in Pharo 6 for Pharo 7) - but when I loaded my commit into a fresh image I realised that none of the (minor) changes I had made to Calypso had been committed.
>
> This is actually quite confusing - and its take me a while to realise that Calypso is a separate project and so when I picked commit on Pharo - this won’t pick up any of the changes in Calypso…. Arrrgggg
>
> So now I’m guessing that I have to follow the same steps that I followed for loading a pharo repo - for Calypso?
>
> But then if I do this - and I propose some fixes to Calypso - how can it work, as it relies on some changes to older pharo core editors that its inserting from?
>
> My changes without Calypso will work (they did in V6) - but then how can someone test those in V7 as Calypso is then the default variable.
>
> I’m in a bit of a twist - how can I proceed?
>
> I’d really like to help improve the situation - as its bugged me for years that its a pain looking stuff up quickly (requiring you to highlight just the right stuff for very obvious things)
>
> Tim

Guillermo Polito

Re: How to contribute to Calypso when it relies on pharo-core editors?

Hi Tim,

Yes, there you're experiencing the limits of our current process. We were studying the usage of git subtrees/submodules/subrepos but none of them seem a satisfying solution for what would give us a smooth contribution process.

Now, we can enhance a bit the current status by adding calypso in the list of iceberg projects. I agree with this. Actually putting Pharo and Iceberg itself there is something we started to do slowly. There was this feeling that people would complain "agh but I only want to see my projects not the system ones". What I believe is that we are used to see and change all packages in the system, that's in our "blood" as pharoers. So seeing all loaded projects may confuse a bit newcomers but empower experts too...

Also, to answer your question about compatibility in Pharo6/7, or even different Pharo7 versions, what I'd say is that the best way to do it is to keep backwards compatibility when possible. Instead of removing/renaming classes or methods, deprecate them. I'm aware that this is not always possible, so trust your criteria.

Guille

On Wed, Jun 20, 2018 at 3:45 AM Tim Mackinnon <[hidden email]> wrote:

Thinking about this more - why doesn’t Calypso appear in iceberg as a separate project alongside iceberg and Pharo?

That’s what’s confusing? And how did it get loaded from it’s git project without it appearing?

Which all makes me think there might need to be an iceberg setting - show/hide system projects so they don’t get in the way of your own projects.

But then if you accidentally save a method in a system class - how are we going to spit it and know?

I hate getting burned when you thought you were on a roll

Tim

Sent from my iPhone

> On 20 Jun 2018, at 02:26, Tim Mackinnon <[hidden email]> wrote:
>
> Hi - so in trying to improve the sendersof/implementors of - I thought I had nailed it (and got working what I had done in Pharo 6 for Pharo 7) - but when I loaded my commit into a fresh image I realised that none of the (minor) changes I had made to Calypso had been committed.
>
> This is actually quite confusing - and its take me a while to realise that Calypso is a separate project and so when I picked commit on Pharo - this won’t pick up any of the changes in Calypso…. Arrrgggg
>
> So now I’m guessing that I have to follow the same steps that I followed for loading a pharo repo - for Calypso?
>
> But then if I do this - and I propose some fixes to Calypso - how can it work, as it relies on some changes to older pharo core editors that its inserting from?
>
> My changes without Calypso will work (they did in V6) - but then how can someone test those in V7 as Calypso is then the default variable.
>
> I’m in a bit of a twist - how can I proceed?
>
> I’d really like to help improve the situation - as its bugged me for years that its a pain looking stuff up quickly (requiring you to highlight just the right stuff for very obvious things)
>
> Tim

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Ben Coman

Re: How to contribute to Calypso when it relies on pharo-core editors?

On 20 June 2018 at 15:38, Guillermo Polito <[hidden email]> wrote:

Hi Tim,

Yes, there you're experiencing the limits of our current process. We were studying the usage of git subtrees/submodules/subrepos but none of them seem a satisfying solution for what would give us a smooth contribution process.

Now, we can enhance a bit the current status by adding calypso in the list of iceberg projects. I agree with this. Actually putting Pharo and Iceberg itself there is something we started to do slowly. There was this feeling that people would complain "agh but I only want to see my projects not the system ones". What I believe is that we are used to see and change all packages in the system, that's in our "blood" as pharoers. So seeing all loaded projects may confuse a bit newcomers but empower experts too...

Just random musing...

It must be common that projects depend on several repos, so perhaps Iceberg could present repos in a two level tree.

The first level is a "project" of which "Pharo" would be one, with second level holding Iceberg and Calypso.

This could be condensed by default so that adding extra default Pharo system repos doesn't clutter much.

If this could somehow tie in with tracking the repos loaded by Baselines, that would be super cool. i.e. Baseline=Project.

Then we don't use the existing subtree/submodule/subrepos, just baselines.

After all, those three standard options all started out as separate scripts tacked onto git - its flexible like that.

cheers -ben

Guillermo Polito

Re: How to contribute to Calypso when it relies on pharo-core editors?

On Wed, Jun 20, 2018 at 1:47 PM Ben Coman <[hidden email]> wrote:

On 20 June 2018 at 15:38, Guillermo Polito <[hidden email]> wrote:
Hi Tim,

Yes, there you're experiencing the limits of our current process. We were studying the usage of git subtrees/submodules/subrepos but none of them seem a satisfying solution for what would give us a smooth contribution process.

Now, we can enhance a bit the current status by adding calypso in the list of iceberg projects. I agree with this. Actually putting Pharo and Iceberg itself there is something we started to do slowly. There was this feeling that people would complain "agh but I only want to see my projects not the system ones". What I believe is that we are used to see and change all packages in the system, that's in our "blood" as pharoers. So seeing all loaded projects may confuse a bit newcomers but empower experts too...

Just random musing...
It must be common that projects depend on several repos, so perhaps Iceberg could present repos in a two level tree.
The first level is a "project" of which "Pharo" would be one, with second level holding Iceberg and Calypso.
This could be condensed by default so that adding extra default Pharo system repos doesn't clutter much.
If this could somehow tie in with tracking the repos loaded by Baselines, that would be super cool. i.e. Baseline=Project.

We are adding the idea of projects to iceberg in the release 1.2 ;)

The idea so far is that an iceberg project will remember at first what is the code subdirectory (so people don't have to type it all over!).

But this opens the idea to have composite projects in the future.

Then we don't use the existing subtree/submodule/subrepos, just baselines.
After all, those three standard options all started out as separate scripts tacked onto git - its flexible like that.

Well, yes and no. That does not quite solve the issue.

Reifying projects add some flexibility, but it does not handle inter git-repository dependencies.

The case is the following:

- pharo is stored in pharo-project/pharo.git

- calypso is stored in pharo-contributions/calypso.git

Regardless how you show them in the UI, let's suppose now that you want to do a change that involves both.

Scenario 1) That is, you have:

pharo v1

calypso v1

And you want to

pharo v2

calypso v2

If the change in either is dependent on the other, and/or for example breaks backwards compatibility, this means there is an implicit dependency between pharo and calypso.

But, next time you build pharo, you load v2, and then you find yourself with:

pharo v2

calypso v1

And everything breaks :)

Scenario 2) This could be solved by first doing a calypso release marking v2, and once that release is finished and public, doing a new pharo v2 release with the proper calypso version. But now, all this "administrative cost" means that there is a time gap between the release of calypso v2 and the release of pharo v2.

In this moment, if you just load bleeding edge version, you may have a build with:

pharo v1

calypso v2

Which may also break if proper care with backwards compatibility was not taken!

Nowadays, both calypso and Iceberg are managed like in scenario 2.

This adds some some safety and order at the cost of bureaucracy (partial releases, care for backwards compatibility).

Generally speaking, I'd like in the future a solution where there is a good tradeoff between safety and flexibility/speed.

Guille