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

[Pharo 7.0-dev] Build #281: 20055-immediateByteSubclass-is-deadcoe

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

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

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Florin Mateoc

On 11/10/2017 9:39 AM, Florin Mateoc wrote: > I think we should also mention that the literal 0.1 is not the number in base ten that we all learned in school, despite > both using base 10 for printing and despite both being printed the same way - this is the crux of the problem. > > But there is such a number in the system, called ScaledDecimal, for which the equality stands: > > 0.1s = (1/10) > > We could have chosen ScaledDecimal as backing for our decimal literals (the literal 0.1 being translated by the > parser/compiler as a ScaledDecimal and only have say the literal 0.1f being translated to an imprecise float) and we > would not have had this problem. We could probably still do it > > Florin Sorry to follow up on myself, but the more I think about it, the more I like my own proposal It would make the choice/compromise to be fast but imprecise explicit > > On 11/10/2017 7:18 AM, Tudor Girba wrote: >> Thanks indeed for the summary. I like this. >> >> Doru >> >> >>> On Nov 10, 2017, at 12:59 PM, raffaello.giulietti(a)lifeware.ch wrote: >>> >>> I would like to summarize my perspective of what emerged from the >>> discussions in the "float & fraction equality bug" trail. >>> >>> The topic is all about mixed operations when both Fractions and Floats >>> are involved in the mix and can be restated as the question of whether >>> it is better to automagically convert the Float to a Fraction or the >>> Fraction to a Float before performing the operation. >>> >>> AFAIK, Pharo currently implements a dual-conversion strategy: >>> (1) it applies Float->Fraction for comparison like =, <=, etc. >>> (2) it applies Fraction->Float for operations like +, *, etc. >>> >>> The reason for (1) is preservation of = as an equivalence and of <= as a >>> total ordering. This is an important point for most Smalltalkers. >>> >>> The reason for (2), however, is dictated by a supposedly better >>> performance. While it is true that Floats perform better than Fractions, >>> I'm not sure that it makes a noticeable difference in everyday uses. >>> Further, the Fraction->Float conversion might even cost more than the >>> gain of using Floats for the real work, the operation itself. The >>> conversion Float->Fraction, on the contrary, is easier. >>> >>> But the major disadvantage of (2) is that it enters the world of limited >>> precision computation (e.g., Floats), which is much harder to >>> understand, less intuitive, more surprising for most of us. >>> >>> >>> >>> So, it might be worthwhile to suppress (2) and consistently apply >>> Float->Fraction conversions whenever needed. It won't make daily >>> computations noticeably slower and helps in preserving more enjoyable >>> properties than the current dual-conversion regime. >>> >>> Also, it won't prevent the numericists or other practitioners to do >>> floating point computations in mixed contexts: just apply explicit >>> Fraction->Float conversions when so desired. >>> >>> This will be at odd with other Smalltalk implementations but might end >>> up being a safer environment. >>> >>> >>> >>> I would like to thank Nicolas in particular for being so quick in >>> answering back and for the good points he raised. >>> >>> Greetings >>> Raffaello >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> >>

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Florin Mateoc

I think we should also mention that the literal 0.1 is not the number in base ten that we all learned in school, despite both using base 10 for printing and despite both being printed the same way - this is the crux of the problem. But there is such a number in the system, called ScaledDecimal, for which the equality stands: 0.1s = (1/10) We could have chosen ScaledDecimal as backing for our decimal literals (the literal 0.1 being translated by the parser/compiler as a ScaledDecimal and only have say the literal 0.1f being translated to an imprecise float) and we would not have had this problem. We could probably still do it Florin On 11/10/2017 7:18 AM, Tudor Girba wrote: > Thanks indeed for the summary. I like this. > > Doru > > >> On Nov 10, 2017, at 12:59 PM, raffaello.giulietti(a)lifeware.ch wrote: >> >> I would like to summarize my perspective of what emerged from the >> discussions in the "float & fraction equality bug" trail. >> >> The topic is all about mixed operations when both Fractions and Floats >> are involved in the mix and can be restated as the question of whether >> it is better to automagically convert the Float to a Fraction or the >> Fraction to a Float before performing the operation. >> >> AFAIK, Pharo currently implements a dual-conversion strategy: >> (1) it applies Float->Fraction for comparison like =, <=, etc. >> (2) it applies Fraction->Float for operations like +, *, etc. >> >> The reason for (1) is preservation of = as an equivalence and of <= as a >> total ordering. This is an important point for most Smalltalkers. >> >> The reason for (2), however, is dictated by a supposedly better >> performance. While it is true that Floats perform better than Fractions, >> I'm not sure that it makes a noticeable difference in everyday uses. >> Further, the Fraction->Float conversion might even cost more than the >> gain of using Floats for the real work, the operation itself. The >> conversion Float->Fraction, on the contrary, is easier. >> >> But the major disadvantage of (2) is that it enters the world of limited >> precision computation (e.g., Floats), which is much harder to >> understand, less intuitive, more surprising for most of us. >> >> >> >> So, it might be worthwhile to suppress (2) and consistently apply >> Float->Fraction conversions whenever needed. It won't make daily >> computations noticeably slower and helps in preserving more enjoyable >> properties than the current dual-conversion regime. >> >> Also, it won't prevent the numericists or other practitioners to do >> floating point computations in mixed contexts: just apply explicit >> Fraction->Float conversions when so desired. >> >> This will be at odd with other Smalltalk implementations but might end >> up being a safer environment. >> >> >> >> I would like to thank Nicolas in particular for being so quick in >> answering back and for the good points he raised. >> >> Greetings >> Raffaello >> > -- > www.tudorgirba.com > www.feenk.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > >

Nov. 10, 2017

[Pharo 7.0-dev] Build #280: 17654-SpecPreDebugWindow-and-subclasses-relies-on-doesNotUnderstand-delegation-to-find-the-stackPane

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

There is a new Pharo build available! The status of the build #280 was: SUCCESS. The Pull Request #461 was integrated: "17654-SpecPreDebugWindow-and-subclasses-relies-on-doesNotUnderstand-delegation-to-find-the-stackPane" Pull request url: https://github.com/pharo-project/pharo/pull/461 Issue Url: https://pharo.fogbugz.com/f/cases/17654 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 10, 2017

Re: [Pharo-dev] Metacello we need automated conflict resolution between Baselines and Configurations

by Dale Henrichs

On 11/10/17 1:14 AM, Peter UhnÃ¡k wrote: > Hi Dale, > > I am aware of locking, but that requires I know all the recursive > dependencies so I can lock them before loading the project itself. > > I can do that locally (and I've done it in the past), but I cannot > easily force that upon users. This also applies for SmalltalkCI which > will just try to load the baseline and will run into the conflict (the > conflict pasted in the first mail actually comes from SCI). Ah .... well getting load conflicts is a feature in that case:) In that case you are trying to load "two different" projects with the same name from incompatible repositories and someone has to decide ... the problem partially likes in the fact that the maintainers of project X haven't committed to a primary repository ... The other part of the problem has to do with being able to specify conflict handling in SmalltalkCI ... the Metacello load command allows you to programmatically decide which side of the conflict wins during the load, but the SCIMetacelloLoadSpec hasn;t quite gotten to the point where the conflct resolution has been exposed At the end of the day, the maintainers of project X need to make up their minds and SmalltalkCI needs to expose the conflict resolution api for Metacllo ... Dale > Thanks, > Peter > > On Thu, Nov 9, 2017 at 11:17 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Peter, > > Metacello locks are supposed to address this kind of problem ... > at this point in time, any project that is loaded from a git > project should be 'locked' using a Metacello lock. > > The lock means that any request to load that project will use the > locked version instead of the version specified in the > configuration/baseline. > > A lock can be applied to a project without actually loading the > project ... > > Presuming that you have a preference towards using the local git > repository for project X, then you can lock project X with a > reference to the local git repository: > > Â Metacello new > > Â Â Â project: 'X'; > > Â Â Â repository: '......'; > > Â Â Â lock. > > ... and from this point on any attempt by Metacello to load > project X will load from the local git repository ... > > Once you have a local clone of a project it is very likely that > you will want to share that repository amongst many of your local > pharo projects and to do that with Metacallo you need to lock > those projects in each of your images, including new images ... > > This can lead to a lot of locking ... I talk about the approach > that I use in tODE to address this problem in two Smalltalks talks > [1] and [2]... > > Dale > > [1] > https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZ… > <https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZ…> > > [2] https://www.youtube.com/watch?v=QshDlH1ADZQ > <https://www.youtube.com/watch?v=QshDlH1ADZQ> > > > > On 11/9/17 12:21 PM, Peter UhnÃ¡k wrote: > > Hi, > > as people are increasingly starting to move to git and > baselines, it is becoming more and more common that there are > loading issues: > > A depends on B and C > > B depends on ConfigurationOfX > > C depends on BaselineOfX > > and then loading fails on > > MetacelloConflictingProjectError: Load Conflict between existing > BaselineOfStateSpecs [baseline] from > github://dionisiydk/StateSpecs:v2.4.x and > ConfigurationOfStateSpecs stable from > http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main > <http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main> > > I imagine that this will become more and more common. > > Can this be resolved in some automated fashion? > > Thanks, > Peter > > > >

Nov. 10, 2017

Re: [Pharo-dev] Catalog problem

by Ben Coman

Thx Sven. That led me to check the url which worked fine. http://catalog.pharo.org/catalog/json Then I had to close and restart the image and its was working fine. So now nothing to examine :(. Minor side issue that I'm ignoring for now (just reporting for completeness)... putting a halt in CatalogProvider>>retrieveProjects and clicking the Catalog <Refresh> button freezes the UI and ALT-. can't break it (and neither does CTRL-. ) The shell console repeatedly cycles following (2 cycles shown), GLMPanelMorph(Morph)>>submorphsDo: Halt CatalogProvider>>retrieveProjects [ self retrieveProjects collect: [ :each | CatalogProject fromDictionary: each ] ] in CatalogProvider>>loadProjects in Block: [ self retrieveProjects... BlockClosure>>on:do: CatalogProvider>>loadProjects CatalogProvider>>loadProjectsIfNeeded CatalogProvider>>projects [ :thisProvider | thisProvider projects ] in [ :a | a list title: 'Available'; in: [ :this | self buildMenuOn: this. self buildContextMenuOn: this ]; display: [ :thisProvider | thisProvider projects ]; format: [ :project | project name ]; icon: [ :project | self iconFor: project ]; filterOn: [ :text :each | each matches: text ]; tags: [ :project | project keywords isNil ifTrue: [ #() ] ifFalse: [ project allKeywords sorted ] ] ] in CatalogBrowser>>buildBrowser in Block: [ :thisProvider | thisProvider projects ] BlockClosure>>glamourValueWithArgs: BlockClosure(ProtoObject)>>glamourValue: GLMListPresentation(GLMPresentation)>>displayValue GLMListPresentation(GLMListingPresentation)>>displayValue GLMTreeMorphModel>>displayValue GLMTreeMorphModel>>roots GLMTreeMorphModel>>rootNodes GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>getList GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>nodeList MorphTreeChunkPager(MorphTreeNavigationBar)>>nodeList MorphTreeChunkPager>>computedHeight GLMPaginatedMorphTreeMorph(PaginatedMorphTreeMorph)>>pagerHeight GLMPaginatedMorphTreeMorph(PaginatedMorphTreeMorph)>>innerBounds GLMPaginatedMorphTreeMorph(Morph)>>layoutBounds GLMPaginatedMorphTreeMorph(Morph)>>minExtent [ :m | | extent frame | "Map the minimal size of the child through the layout frame. Note: This is done here and not in the child because its specific for proportional layouts. Perhaps we'll generalize this for table layouts but I'm not sure how and when." extent := m minExtent. frame := m layoutFrame. frame ifNotNil: [ extent := frame minExtentFrom: extent ]. min := min max: extent ] in ProportionalLayout>>minExtentOf:in: in Block: [ :m | ... Array(SequenceableCollection)>>do: GLMPanelMorph(Morph)>>submorphsDo: ProportionalLayout>>minExtentOf:in: GLMPanelMorph(Morph)>>minExtent [ :m | | sizeX sizeY | m disableTableLayout ifFalse: [ n := n + 1. size := m minExtent. sizeX := size x. sizeY := size y. sizeX < minX ifTrue: [ sizeX := minX ] ifFalse: [ sizeX > maxX ifTrue: [ sizeX := maxX ] ]. sizeY < minY ifTrue: [ sizeY := minY ] ifFalse: [ sizeY > maxY ifTrue: [ sizeY := maxY ] ]. height := height + sizeY. sizeX > width ifTrue: [ width := sizeX ] ] ] in TableLayout>>minExtentVertical: in Block: [ :m | ... Array(SequenceableCollection)>>do: GLMPanelMorph(Morph)>>submorphsDo: Halt CatalogProvider>>retrieveProjects [ self retrieveProjects collect: [ :each | CatalogProject fromDictionary: each ] ] in CatalogProvider>>loadProjects in Block: [ self retrieveProjects... BlockClosure>>on:do: CatalogProvider>>loadProjects CatalogProvider>>loadProjectsIfNeeded CatalogProvider>>projects [ :thisProvider | thisProvider projects ] in [ :a | a list title: 'Available'; in: [ :this | self buildMenuOn: this. self buildContextMenuOn: this ]; display: [ :thisProvider | thisProvider projects ]; format: [ :project | project name ]; icon: [ :project | self iconFor: project ]; filterOn: [ :text :each | each matches: text ]; tags: [ :project | project keywords isNil ifTrue: [ #() ] ifFalse: [ project allKeywords sorted ] ] ] in CatalogBrowser>>buildBrowser in Block: [ :thisProvider | thisProvider projects ] BlockClosure>>glamourValueWithArgs: BlockClosure(ProtoObject)>>glamourValue: GLMListPresentation(GLMPresentation)>>displayValue GLMListPresentation(GLMListingPresentation)>>displayValue GLMTreeMorphModel>>displayValue GLMTreeMorphModel>>roots GLMTreeMorphModel>>rootNodes GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>getList GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>nodeList MorphTreeChunkPager(MorphTreeNavigationBar)>>nodeList MorphTreeChunkPager>>computedHeight GLMPaginatedMorphTreeMorph(PaginatedMorphTreeMorph)>>pagerHeight GLMPaginatedMorphTreeMorph(PaginatedMorphTreeMorph)>>innerBounds GLMPaginatedMorphTreeMorph(Morph)>>layoutBounds GLMPaginatedMorphTreeMorph(Morph)>>minExtent [ :m | | extent frame | "Map the minimal size of the child through the layout frame. Note: This is done here and not in the child because its specific for proportional layouts. Perhaps we'll generalize this for table layouts but I'm not sure how and when." extent := m minExtent. frame := m layoutFrame. frame ifNotNil: [ extent := frame minExtentFrom: extent ]. min := min max: extent ] in ProportionalLayout>>minExtentOf:in: in Block: [ :m | ... Array(SequenceableCollection)>>do: GLMPanelMorph(Morph)>>submorphsDo: ProportionalLayout>>minExtentOf:in: GLMPanelMorph(Morph)>>minExtent [ :m | | sizeX sizeY | m disableTableLayout ifFalse: [ n := n + 1. size := m minExtent. sizeX := size x. sizeY := size y. sizeX < minX ifTrue: [ sizeX := minX ] ifFalse: [ sizeX > maxX ifTrue: [ sizeX := maxX ] ]. sizeY < minY ifTrue: [ sizeY := minY ] ifFalse: [ sizeY > maxY ifTrue: [ sizeY := maxY ] ]. height := height + sizeY. sizeX > width ifTrue: [ width := sizeX ] ] ] in TableLayout>>minExtentVertical: in Block: [ :m | ... Array(SequenceableCollection)>>do: GLMPanelMorph(Morph)>>submorphsDo: Halt CatalogProvider>>retrieveProjects On Fri, Nov 10, 2017 at 8:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Check CatalogProvider. It should download the catalog from the cloud and > cache it locally. If not you can work from there on to see what is wrong. > > > On 10 Nov 2017, at 13:32, Ben Coman <btc(a)openinworld.com> wrote: > > > > Today I downloaded Pharo and found Catalog to be empty. > > http://files.pharo.org/platform/Pharo6.1-64-linux.zip > > > > cheers -ben > > > > >

Nov. 10, 2017

Re: [Pharo-dev] Tonel line end convention

by Peter UhnÃ¡k

Does iceberg respect git line ending settings? https://help.github.com/articles/dealing-with-line-endings/ On Fri, Nov 10, 2017 at 2:02 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Can we add an empty line at the end of every tonel file? GitHub diff tools > work better that way and for the rest it shouldn't matter. > > On Fri, Nov 10, 2017 at 8:26 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> >> > On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > Hi, >> > >> > I am wondering if the current approach regarding the Tonel line end >> convention is a good idea. >> > >> > TonelWriter>>#newLine >> > ^ OSPlatform current lineEnding >> > >> > Although it is no problem to write Pharo code that transparently deals >> with (accepts) any line end convention, not specifying a fixed line end >> convention is bound to lead to version control problems, in my opinion. >> > >> > Person 1 on platform A has line end convention #cr. After editing a >> single method, the .class.st is generated. Now the whole file is using >> #cr. From the standpoint of the version control system, *every* line is now >> potentially changed (when the previous line end convention was different). >> > >> > Or am I missing something that mitigates this ? >> >> git can handle (ignore) line endings when diffing. >> and also git can checkout with platform line endings, which means you can >> switch between mac/linux and windows *and* you can keep your files readable >> (which is the purpose of using platform line ending). >> >> Esteban >> >> > >> > Sven >> > >> > >> >> >> >

Nov. 10, 2017

Re: [Pharo-dev] Catalog problem

by Peter UhnÃ¡k

Try closing Pharo and opening it again... this is imho due to slow Inria servers and I've encountered it many times. On Fri, Nov 10, 2017 at 1:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Check CatalogProvider. It should download the catalog from the cloud and > cache it locally. If not you can work from there on to see what is wrong. > > > On 10 Nov 2017, at 13:32, Ben Coman <btc(a)openinworld.com> wrote: > > > > Today I downloaded Pharo and found Catalog to be empty. > > http://files.pharo.org/platform/Pharo6.1-64-linux.zip > > > > cheers -ben > > > > >

Nov. 10, 2017

Re: [Pharo-dev] Tonel line end convention

by Gabriel Cotelli

Can we add an empty line at the end of every tonel file? GitHub diff tools work better that way and for the rest it shouldn't matter. On Fri, Nov 10, 2017 at 8:26 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > I am wondering if the current approach regarding the Tonel line end > convention is a good idea. > > > > TonelWriter>>#newLine > > ^ OSPlatform current lineEnding > > > > Although it is no problem to write Pharo code that transparently deals > with (accepts) any line end convention, not specifying a fixed line end > convention is bound to lead to version control problems, in my opinion. > > > > Person 1 on platform A has line end convention #cr. After editing a > single method, the .class.st is generated. Now the whole file is using > #cr. From the standpoint of the version control system, *every* line is now > potentially changed (when the previous line end convention was different). > > > > Or am I missing something that mitigates this ? > > git can handle (ignore) line endings when diffing. > and also git can checkout with platform line endings, which means you can > switch between mac/linux and windows *and* you can keep your files readable > (which is the purpose of using platform line ending). > > Esteban > > > > > Sven > > > > > > >

Nov. 10, 2017

Re: [Pharo-dev] Catalog problem

by Sven Van Caekenberghe

Check CatalogProvider. It should download the catalog from the cloud and cache it locally. If not you can work from there on to see what is wrong. > On 10 Nov 2017, at 13:32, Ben Coman <btc(a)openinworld.com> wrote: > > Today I downloaded Pharo and found Catalog to be empty. > http://files.pharo.org/platform/Pharo6.1-64-linux.zip > > cheers -ben >

Nov. 10, 2017