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

[Pharo 7.0-dev] Build #521: 21282 Use "utilities" category in FileStream

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

There is a new Pharo build available! The status of the build #521 was: SUCCESS. The Pull Request #836 was integrated: "21282 Use "utilities" category in FileStream" Pull request url: https://github.com/pharo-project/pharo/pull/836 Issue Url: https://pharo.fogbugz.com/f/cases/21282 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 11, 2018

Re: [Pharo-dev] About method comments

by lb

Hi, Stef I have an idea for this problem, 1. method should have it's comment like class comment 2. method comment has two versions, one for developer another for reader 3. developder's comment will be saved in source or changes file 4. reader's comment will be saved in its own file 5. system browser can load reader's comment of method when you want to read or write reader can write his comment using his native language, we can share all reader's comments on internet. Best regards Bing Liang

Feb. 11, 2018

Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

by Ben Coman

On 11 February 2018 at 02:28, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > P.P.S. I think more thought needs to be given to whether mixing > > updates from both the remote and disk working directory in the one > > pane is beneficial? > > As an alternative, perhaps some side-scrolling GTInspector-like panes > > Image <--> Working Directory <--> Remote <--> Server(github) > > would better represent the git model. > > Or maybe statically position those panes in one window with buttons on > > directed lines showing which way and how far a commit moves when that > > button is pushed. > > > I was saying to esteban that the UI should let the user understand > where the code is so I like you > > > Image <--> Working Directory <--> Remote <--> Server(github) > > Mine was > > > Image <--> Local repository <--> Remote > > Stef > > Actually the fourth one might be redundant. The way you find out about the fourth one is you Fetch into the third one. cheers -ben

Feb. 11, 2018

[Pharo 7.0-dev] Build #520: 21280 Remove double dots in #cleanUpChangeSetForClassNames:

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

There is a new Pharo build available! The status of the build #520 was: SUCCESS. The Pull Request #834 was integrated: "21280 Remove double dots in #cleanUpChangeSetForClassNames:" Pull request url: https://github.com/pharo-project/pharo/pull/834 Issue Url: https://pharo.fogbugz.com/f/cases/21280 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 10, 2018

[Pharo 7.0-dev] Build #519: 21277 Improve comment for byteToUnicodeSpec and typo fix

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

There is a new Pharo build available! The status of the build #519 was: SUCCESS. The Pull Request #831 was integrated: "21277 Improve comment for byteToUnicodeSpec and typo fix" Pull request url: https://github.com/pharo-project/pharo/pull/831 Issue Url: https://pharo.fogbugz.com/f/cases/21277 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 10, 2018

[Pharo 7.0-dev] Build #518: 21268 Cleanup AST-Tests-Core package

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

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

Feb. 10, 2018

[Pharo 7.0-dev] Build #517: 21266 Cleanup testAddMCPackageForCategoryAlreadyExistingDoesNotCreateAPackage

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

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

Feb. 10, 2018

Re: [Pharo-dev] interactive method definition (was Re: Calypso wishlist)

by Stephane Ducasse

In fact I'm stupid because I already coded it by extending the parser and I lost the code. I should look around or redo it. On Sat, Feb 10, 2018 at 7:10 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Is this your ideal, or mainly to align with Tonel? Because it seems Tonel >> was developed >> without much consideration of interactive method definition -- which is fine >> in as much as >> Tonel was designed to quickly overcome a specific problem with Windows+Git, >> but it >> Tonel shouldn't be set in stone since its introduction changes the >> environment >> and stimulates further thinking on requirements. > > Not only. We decided that the methods syntax in tonel could be used in browser > and in email. I have this proposal since before ESUG in lugano (2005) > so I really thought about it > a lot. This is not by accident that the code in all my book follow > nearly this shape. > The tonel structure is nice because it mimics also other languages. > > fooSignature { > > } > > >> Amongst your many priorities, could you ask someone familiar with changing >> compiler syntax >> have a serious look at implementing both ways: >> 1. Tonel syntax for interactive method definition > > Yes but we are really busy > And yes we want this. So we should do it. > >> 2. Named block parameters for interactive method definition > > 2 mega sucks. > And we will not do it. Sorry. > > >> to determine practically which one is preferred and easier to support. > > I will veto 2. And I will be really strong on it. > I'm teaching Pharo and this is enough. > >> And feed that into determining whether syntax should adapt to Tonel >> or whether Tonel should adapt to the latter. It would be better to do this >> earlier while Tonel is young before it becomes more widely used by other >> dialects. > > Tonel method definition will not change. > > >> Also btw, would having named block parameters possibly unify more methods >> and blocks? >> (only a random thought, I'm not familiar with the low level distinction) > > This is not because they look the same that in the conceptual model > they should. > Now I would like to have optional parameter value (but it can be a bit > touchy since there > are many design decision to take and it impacts senders and the rest. > > > >> >> cheers -ben >> >> >> P.S. should Tonel include a format-version field on the first line? >> Its seems a good practice even if the format never does change for a long >> time. > > Tonel has a property file that encodes metadata.

Feb. 10, 2018

Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

by Stephane Ducasse

> > P.P.S. I think more thought needs to be given to whether mixing > updates from both the remote and disk working directory in the one > pane is beneficial? > As an alternative, perhaps some side-scrolling GTInspector-like panes > Image <--> Working Directory <--> Remote <--> Server(github) > would better represent the git model. > Or maybe statically position those panes in one window with buttons on > directed lines showing which way and how far a commit moves when that > button is pushed. I was saying to esteban that the UI should let the user understand where the code is so I like you > Image <--> Working Directory <--> Remote <--> Server(github) Mine was > Image <--> Local repository <--> Remote Stef

Feb. 10, 2018

Re: [Pharo-dev] interactive method definition (was Re: Calypso wishlist)

by Stephane Ducasse

> Is this your ideal, or mainly to align with Tonel? Because it seems Tonel > was developed > without much consideration of interactive method definition -- which is fine > in as much as > Tonel was designed to quickly overcome a specific problem with Windows+Git, > but it > Tonel shouldn't be set in stone since its introduction changes the > environment > and stimulates further thinking on requirements. Not only. We decided that the methods syntax in tonel could be used in browser and in email. I have this proposal since before ESUG in lugano (2005) so I really thought about it a lot. This is not by accident that the code in all my book follow nearly this shape. The tonel structure is nice because it mimics also other languages. fooSignature { } > Amongst your many priorities, could you ask someone familiar with changing > compiler syntax > have a serious look at implementing both ways: > 1. Tonel syntax for interactive method definition Yes but we are really busy And yes we want this. So we should do it. > 2. Named block parameters for interactive method definition 2 mega sucks. And we will not do it. Sorry. > to determine practically which one is preferred and easier to support. I will veto 2. And I will be really strong on it. I'm teaching Pharo and this is enough. > And feed that into determining whether syntax should adapt to Tonel > or whether Tonel should adapt to the latter. It would be better to do this > earlier while Tonel is young before it becomes more widely used by other > dialects. Tonel method definition will not change. > Also btw, would having named block parameters possibly unify more methods > and blocks? > (only a random thought, I'm not familiar with the low level distinction) This is not because they look the same that in the conceptual model they should. Now I would like to have optional parameter value (but it can be a bit touchy since there are many design decision to take and it impacts senders and the rest. > > cheers -ben > > > P.S. should Tonel include a format-version field on the first line? > Its seems a good practice even if the format never does change for a long > time. Tonel has a property file that encodes metadata.

Feb. 10, 2018