December 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #55: 22801 Small cleanups in TRBProgramNodeVisitor

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #55 was: SUCCESS. The Pull Request #2093 was integrated: "22801 Small cleanups in TRBProgramNodeVisitor" Pull request url: https://github.com/pharo-project/pharo/pull/2093 Issue Url: https://pharo.fogbugz.com/f/cases/22801 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

On Tue, 18 Dec 2018 at 03:19, Torsten Bergmann <astares(a)gmx.de> wrote: > > Model 2: Work with several open branches - one per Pharo version > ================================================================ > > In DesktopManager which is on > https://github.com/astares/Pharo-DesktopManager I do it differently. I > wanted to maintain it for Pharo7 > now but wanted to still easily backport changes to Pharo 6. > > For this project I maintain therefore two special branches "pharo6" and > "pharo7" - each for a particular Pharo version. > > This allows me to maintain the differences between the Pharo 6 and Pharo 7 > version by using the two distinguished branches > and backport from the "pharo7" branch easily to the "pharo6" branch if > necessary. > In the past I've contemplated that this form might be a good way to manage cross-platform code, but also having a "master" and merge from there into each "pharo6" , "pharo7" , "squeakN" platform-branch if/when they get some git tools. The workflow might then be that users of a particular platform push can issue a PR to that particular platform-branch to make the changes easy to see, and integrate into "master" if useful. cheers -ben The second model fits better if you provide packages that you would like to > maintain for several Pharo versions from 6.0 > onwards. I now also use it to maintain "QuickAccess", "OSWindows", > "OSUnix", ... and others. >

Dec. 18, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Petr Fischer

I have that feeling too - critiques pane is annoying + occupying too much place - what about showing critiques inline only (in the line nubers and breakpoint markers left pane)? This choice existed for the old Nautilus browser - but I can't find it for Calypso. pf > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

Hi Torsten, Thanks for the clear explication, I think I will most probably go for scenario 1, but it is good to at least know about scenario 2. I'll sure come back if I cannot get this working on my own. Sven > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > Maybe we have better ideas when we move forward with the transition to git for the majority of external > projects. But for the time being I guess we stick to Catalog as a replacement is still not available. > It might not be the best solution - but at least it works. The only downside is that it is still dependent > on SmalltalkHub due to the MetaRepos hosted there. > > To answer your questions: > > For Pharo 7.0 there is a regular MetaRepo > > http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo70 > > that one can use. The (re)indexing each day is still based on providing a ConfigurationOf... there. > We will create a MetaRepoForPharo80 once Pharo 7 is released and Pharo 8 work starts. > > Catalog also does not work directly with BaselineOf - so you point from your ConfigurationOf to a BaselineOf in Github > as the examples below will demonstrate. > > So while the basic mechanism of Catalog did not change and works as before the usage of git and GitHub gives you now more > flexibility in the management of your (catalog) projects. > > I already use this for a few of my projects that I moved to GitHub and I would share some experience here. > Basically I tried now two different models: > > Model 1: Work with a single branch and close a release using a tag as version in git > =================================================================================== > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > use the git tagging to mark release like milestone of your project ("versions"). > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > and in https://github.com/astares/Tealight) > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > and then reference this git tagged version in my ConfigurationOfTealight: > > v0_0_4: spec > <version: '0.0.4'> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec > baseline: 'Tealight' with: [ > spec > className: 'BaselineOfTealight'; > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > another story). > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... > > Model 2: Work with several open branches - one per Pharo version > ================================================================ > > In DesktopManager which is on https://github.com/astares/Pharo-DesktopManager I do it differently. I wanted to maintain it for Pharo7 > now but wanted to still easily backport changes to Pharo 6. > > For this project I maintain therefore two special branches "pharo6" and "pharo7" - each for a particular Pharo version. > > So in the ConfigurationOfDesktop as you will find in MetaRepoForPharo70 I just point to the Baseline > with only the difference of the branch: > > ------------------------------------------------------------------------------------------------------------ > pharo6: spec > <version: '6.0'> > > spec for: #'common' do: [ > spec > baseline: 'DesktopManager' with: [ > spec > className: 'BaselineOfDesktopManager'; > repository: 'github://astares/Pharo-DesktopManager:pharo6/src' ]] > ------------------------------------------------------------------------------------------------------------ > pharo7: spec > <version: '7.0'> > > spec for: #'common' do: [ > spec > baseline: 'DesktopManager' with: [ > spec > className: 'BaselineOfDesktopManager'; > repository: 'github://astares/Pharo-DesktopManager:pharo7/src' ]] > ------------------------------------------------------------------------------------------------------------ > stable: spec > <symbolicVersion: #'stable'> > > spec for: #'pharo5.x' version: '0.2.0'. "old way using versioning with Monticello/Metacello and StHub" > spec for: #'pharo6.x' version: '6.0'. "still open version branch from Pharo 6 using git and GitHub" > spec for: #'pharo7.x' version: '7.0'. "still open version branch from Pharo 7 using git and GitHub" > ------------------------------------------------------------------------------------------------------------ > > This allows me to maintain the differences between the Pharo 6 and Pharo 7 version by using the two distinguished branches > and backport from the "pharo7" branch easily to the "pharo6" branch if necessary. > > As no tagging with explicit versioning is involved here the branch for each Pharo version is always open for new > additions/future fixes. > > The first model is close to what one is used to from the past: having reproducible fixed tagged versions referenced > from the ConfigurationOf... > > The second model fits better if you provide packages that you would like to maintain for several Pharo versions from 6.0 > onwards. I now also use it to maintain "QuickAccess", "OSWindows", "OSUnix", ... and others. > > Hope this helps a little bit. If not just ask. > > Have fun > T. > > >> Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr >> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: [Pharo-dev] Catalog Entries >> >> Hi, >> >> So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. >> >> I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. >> >> Can one define Catalog entries using BaselineOfXYZ ? >> Is that recommended ? >> Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? >> >> Sven >> >> >> >

Dec. 17, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Hi Sven, Maybe we have better ideas when we move forward with the transition to git for the majority of external projects. But for the time being I guess we stick to Catalog as a replacement is still not available. It might not be the best solution - but at least it works. The only downside is that it is still dependent on SmalltalkHub due to the MetaRepos hosted there. To answer your questions: For Pharo 7.0 there is a regular MetaRepo http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo70 that one can use. The (re)indexing each day is still based on providing a ConfigurationOf... there. We will create a MetaRepoForPharo80 once Pharo 7 is released and Pharo 8 work starts. Catalog also does not work directly with BaselineOf - so you point from your ConfigurationOf to a BaselineOf in Github as the examples below will demonstrate. So while the basic mechanism of Catalog did not change and works as before the usage of git and GitHub gives you now more flexibility in the management of your (catalog) projects. I already use this for a few of my projects that I moved to GitHub and I would share some experience here. Basically I tried now two different models: Model 1: Work with a single branch and close a release using a tag as version in git =================================================================================== This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and use the git tagging to mark release like milestone of your project ("versions"). This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog and in https://github.com/astares/Tealight) So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases and then reference this git tagged version in my ConfigurationOfTealight: v0_0_4: spec <version: '0.0.4'> spec for: #'common' do: [ spec blessing: #'stable'. spec baseline: 'Tealight' with: [ spec className: 'BaselineOfTealight'; repository: 'github://astares/Tealight:0.0.4/repository' ]] The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is another story). So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... Model 2: Work with several open branches - one per Pharo version ================================================================ In DesktopManager which is on https://github.com/astares/Pharo-DesktopManager I do it differently. I wanted to maintain it for Pharo7 now but wanted to still easily backport changes to Pharo 6. For this project I maintain therefore two special branches "pharo6" and "pharo7" - each for a particular Pharo version. So in the ConfigurationOfDesktop as you will find in MetaRepoForPharo70 I just point to the Baseline with only the difference of the branch: ------------------------------------------------------------------------------------------------------------ pharo6: spec <version: '6.0'> spec for: #'common' do: [ spec baseline: 'DesktopManager' with: [ spec className: 'BaselineOfDesktopManager'; repository: 'github://astares/Pharo-DesktopManager:pharo6/src' ]] ------------------------------------------------------------------------------------------------------------ pharo7: spec <version: '7.0'> spec for: #'common' do: [ spec baseline: 'DesktopManager' with: [ spec className: 'BaselineOfDesktopManager'; repository: 'github://astares/Pharo-DesktopManager:pharo7/src' ]] ------------------------------------------------------------------------------------------------------------ stable: spec <symbolicVersion: #'stable'> spec for: #'pharo5.x' version: '0.2.0'. "old way using versioning with Monticello/Metacello and StHub" spec for: #'pharo6.x' version: '6.0'. "still open version branch from Pharo 6 using git and GitHub" spec for: #'pharo7.x' version: '7.0'. "still open version branch from Pharo 7 using git and GitHub" ------------------------------------------------------------------------------------------------------------ This allows me to maintain the differences between the Pharo 6 and Pharo 7 version by using the two distinguished branches and backport from the "pharo7" branch easily to the "pharo6" branch if necessary. As no tagging with explicit versioning is involved here the branch for each Pharo version is always open for new additions/future fixes. The first model is close to what one is used to from the past: having reproducible fixed tagged versions referenced from the ConfigurationOf... The second model fits better if you provide packages that you would like to maintain for several Pharo versions from 6.0 onwards. I now also use it to maintain "QuickAccess", "OSWindows", "OSUnix", ... and others. Hope this helps a little bit. If not just ask. Have fun T. > Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Catalog Entries > > Hi, > > So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. > > I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. > > Can one define Catalog entries using BaselineOfXYZ ? > Is that recommended ? > Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? > > Sven > > >

Dec. 17, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Sven Van Caekenberghe

Thanks, Denis, for the swift reply. What is the solution, though ? What do you think should happen ? Make the constant smaller, like the height of 1 row ? > On 17 Dec 2018, at 18:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Sven. > > I checked problem and found following method: > > FTTableMorph >> minHeight > ^ 100 > > It prevents full critiques widget to be small. > > There is probably a bug in morphic which does not set up this "correct" extent by default. In my case when I browse your method in fresh image only three rows are visible in critiques view. But as soon as I start resizing this pane it becomes bigger and unminimizable. > > Ð¿Ð½, 17 Ð´ÐµÐº. 2018 Ð³. Ð² 17:14, Sven Van Caekenberghe <sven(a)stfx.eu>: > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > <Screenshot 2018-12-17 at 17.19.35.png> > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven >

Dec. 17, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

Hi Sven. I checked problem and found following method: FTTableMorph >> minHeight ^ 100 It prevents full critiques widget to be small. There is probably a bug in morphic which does not set up this "correct" extent by default. In my case when I browse your method in fresh image only three rows are visible in critiques view. But as soon as I start resizing this pane it becomes bigger and unminimizable.

Dec. 17, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

Hi Sven. I checked problem and found following method: FTTableMorph >> minHeight ^ 100 It prevents full critiques widget to be small. There is probably a bug in morphic which does not set up this "correct" extent by default. In my case when I browse your method in fresh image only three rows are visible in critiques view. But as soon as I start resizing this pane it becomes bigger and unminimizable. Ð¿Ð½, 17 Ð´ÐµÐº. 2018 Ð³. Ð² 17:14, Sven Van Caekenberghe <sven(a)stfx.eu>: > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at > the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven > >

Dec. 17, 2018

[Pharo 7.0] Build #54: 22793 Cleanup AndreasSystemProfilerTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #54 was: SUCCESS. The Pull Request #2088 was integrated: "22793 Cleanup AndreasSystemProfilerTest" Pull request url: https://github.com/pharo-project/pharo/pull/2088 Issue Url: https://pharo.fogbugz.com/f/cases/22793 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 17, 2018

Huge Critiques Area in Calypso in Pharo 7

by Sven Van Caekenberghe

I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: Why is that ? I can't resize it to be smaller. On a smaller screen this takes up way too much space. Can't we have a widget to remove/collapse that area ? Not a setting. Sven

Dec. 17, 2018