November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] LayoutFrame bug

by Christian Kellermann

Hi! * Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> [171108 13:48]: > Hi, > don't you get nice red-cross when opening a browser and selecting comment? > (Pharo7.0-32bit-b5ec533.image) > > The problem is LayoutFrame having a Point instead of Number in > fraction/offset inst. var. > > So I defined two horrible hacks in order to be able to work with Pharo > > Point>>@ n ^x @ n > Point>>asInteger ^x asInteger > > then could instrument the LayoutFrame inst. var. setters with horrible > checks like: > aNumber isNumber ifFalse: [ self halt]. > > And after a few seconds of IDE usage: > > AbstractNautilusUI>>buildCodePanelWithCommentOnRight > ...snip... > sourceCodePanel > addMorph: commentWidget > fullFrame: (LayoutFrame identity leftFraction: 0.5@0 ; > leftOffset: delta). > > Huh! it's as pleasant as not eating own dog food > I think this comes from a recent refactoring. I can hardly use in image > tools to trace it. > Iceberg bugs, MC has lost ancestry and is just good at synchronizing disk > working copy with image working copy, but there is github & git API: > > https://github.com/pharo-project/pharo/commit/042baad47fddb63db2dd0beefeec6… > > As it's nearly impossible to make giant refactorings like this without > human error, > and as it's as impossible to review pull request with many lines of code, > I wonder if it is possible to automate those with rewrite rules... > > I let you finish the work (open issue, patch, commit, etc...) Nice find, I have been stumbling onto this yesterday. Hard to spot this line 1612 in a huge commit like this. Thanks for debugging it! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease.

Nov. 8, 2017

LayoutFrame bug

by Nicolas Cellier

Hi, don't you get nice red-cross when opening a browser and selecting comment? (Pharo7.0-32bit-b5ec533.image) The problem is LayoutFrame having a Point instead of Number in fraction/offset inst. var. So I defined two horrible hacks in order to be able to work with Pharo Point>>@ n ^x @ n Point>>asInteger ^x asInteger then could instrument the LayoutFrame inst. var. setters with horrible checks like: aNumber isNumber ifFalse: [ self halt]. And after a few seconds of IDE usage: AbstractNautilusUI>>buildCodePanelWithCommentOnRight ...snip... sourceCodePanel addMorph: commentWidget fullFrame: (LayoutFrame identity leftFraction: 0.5@0 ; leftOffset: delta). Huh! it's as pleasant as not eating own dog food I think this comes from a recent refactoring. I can hardly use in image tools to trace it. Iceberg bugs, MC has lost ancestry and is just good at synchronizing disk working copy with image working copy, but there is github & git API: https://github.com/pharo-project/pharo/commit/042baad47fddb63db2dd0beefeec6… As it's nearly impossible to make giant refactorings like this without human error, and as it's as impossible to review pull request with many lines of code, I wonder if it is possible to automate those with rewrite rules... I let you finish the work (open issue, patch, commit, etc...)

Nov. 8, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #268: 20650-Release-cleanup-failures

by Pavel Krivanek

This is the Heisenbug - it appears only if you do not add a code to study it. -- Pavel 2017-11-08 13:05 GMT+01:00 <ci-pharo-ci-jenkins2(a)inria.fr>: > There is a new Pharo build available! > > The status of the build #268 was: SUCCESS. > > The Pull Request #448 was integrated: "20650-Release-cleanup-failures" > Pull request url: https://github.com/pharo-project/pharo/pull/448 > > Issue Url: https://pharo.fogbugz.com/f/cases/20650 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development/268/ >

Nov. 8, 2017

[Pharo 7.0-dev] Build #268: 20650-Release-cleanup-failures

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

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

Nov. 8, 2017

Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by stephan

On 07-11-17 22:34, Pavel Krivanek wrote: > I successfully loaded Seaside into minimal Pharo 7 image: > > http://forum.world.st/Seaside-on-minimal-Pharo-7-0-td4979763.html Well, loading code that adds methods to the still existing traits works. But if those traits are no longer used, that might result in silent failure. That actually needs a quality rule (or rewrite to also flatten) Stephan

Nov. 8, 2017

Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Sven Van Caekenberghe

> On 7 Nov 2017, at 22:59, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Sven > > 2017-11-07 21:35 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Like I said in another email, for example STON adds methods to Class, MetaClass and ClassDescription *Traits*. Now it has to add to the classes itself (right ?). So a single code base cannot deal with Pharo 7 and older version without splitting. I like to keep simple projects like STON simple (Seaside is huge in comparison and deals with this stuff all the time and already has the complex infrastructure for it). > > I think it should not be problem for compatibility. Because with flattening you will just has duplication of code for classes and traits but classes and traits existed in Pharo all the time. So flattened version of STON will correctly work in older Pharo's. I didn't look careful enough to realise you made your own fork. Still, trying Metacello new baseline:'Seaside3'; repository: 'github://pavel-krivanek/Seaside:minimalPharo/repository'; load. In full Pharo 7, I get: MetacelloNameNotDefinedError: project group, or package named: 'Seaside-Pharo-Development' not found when used in requires: or includes: field of package: 'Seaside-Tests-Pharo-Development' for version: baseline of BaselineOfSeaside3. Thanks for helping out. Sven

Nov. 7, 2017

Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Denis Kudriashov

Hi Sven 2017-11-07 21:35 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Like I said in another email, for example STON adds methods to Class, > MetaClass and ClassDescription *Traits*. Now it has to add to the classes > itself (right ?). So a single code base cannot deal with Pharo 7 and older > version without splitting. I like to keep simple projects like STON simple > (Seaside is huge in comparison and deals with this stuff all the time and > already has the complex infrastructure for it). > I think it should not be problem for compatibility. Because with flattening you will just has duplication of code for classes and traits but classes and traits existed in Pharo all the time. So flattened version of STON will correctly work in older Pharo's.

Nov. 7, 2017

Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Pavel Krivanek

I successfully loaded Seaside into minimal Pharo 7 image: http://forum.world.st/Seaside-on-minimal-Pharo-7-0-td4979763.html -- Pavel 2017-11-07 21:11 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Nobody (trying to use|using) Seaside on Pharo 7 ?? > > > On 6 Nov 2017, at 09:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > [ > > > > Max replied on the Seaside ML where I originally posted: > > > >> We don't have a build for Pharo 7 yet. Loading from github would be the > recommended way. A quick look makes me think that it will require a bit of > work to get the baseline set up correctly. I can't promise anything before > next weekend. > > > > > > I think it is important that Seaside works on Pharo 7, it is an > important use case and test during development, and very necessary as well. > > > > ] > > > > I am stuck trying to move my main development to Pharo 7 because I have > trouble loading Seaside (which I normally do indirectly by loading the > Bootstrap project). Here is my dependency: > > > > project: 'Bootstrap' with: [ > > spec > > className: 'ConfigurationOfBootstrap'; > > repository: 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/ > main/'; > > versionString: #stable ] > > > > I also tried the following: > > > > Metacello new > > baseline:'Seaside3'; > > repository: 'github://SeasideSt/Seaside:master/repository'; > > load. > > > > What is the right/recommended way to do it ? > > > > Thx, > > > > Sven > > >

Nov. 7, 2017

Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Sven Van Caekenberghe

> On 7 Nov 2017, at 21:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 7 Nov 2017, at 17:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 7 Nov 2017, at 21:17, stephan <stephan(a)stack.nl> wrote: >>> >>> On 07-11-17 21:11, Sven Van Caekenberghe wrote: >>>> Nobody (trying to use|using) Seaside on Pharo 7 ?? >>> >>> I already did one pull request. >> >> OK, thanks, let's hope things keep moving forward. I am ready to test and help. >> >>> That is not enough because of the flattening of traits >> >> Yes, that is a though one for external libraries. > > why? (not putting it in doubt, just wanting to know ;) ) Like I said in another email, for example STON adds methods to Class, MetaClass and ClassDescription *Traits*. Now it has to add to the classes itself (right ?). So a single code base cannot deal with Pharo 7 and older version without splitting. I like to keep simple projects like STON simple (Seaside is huge in comparison and deals with this stuff all the time and already has the complex infrastructure for it). > Esteban > >> >>> Stephan

Nov. 7, 2017

Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by stephan

On 07-11-17 21:25, Esteban Lorenzano wrote: >> On 7 Nov 2017, at 17:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Yes, that is a though one for external libraries. > > why? (not putting it in doubt, just wanting to know ;) ) Ah, well, it just means that we'll want to replace some code written for pharo 3 or 4 and add it there. Just unplanned work to keep up with Pharo changes. And would have been better handled as a rewrite rule, I think. Stephan

Nov. 7, 2017