- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #810: 21794 Correctly deprecate #displayProgressAt:from:to:during: and cleaâ¦
by ci-pharo-ci-jenkins2＠inria.fr April 26, 2018

April 26, 2018

There is a new Pharo build available! The status of the build #810 was: SUCCESS. The Pull Request #1265 was integrated: "21794 Correctly deprecate #displayProgressAt:from:to:during: and cleaâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/1265 Issue Url: https://pharo.fogbugz.com/f/cases/21794 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #809: Move AuthorTest, SmalltalkImageTest, SystemDictionaryTest and other to package "System-Support-Tests"
by ci-pharo-ci-jenkins2＠inria.fr April 26, 2018

April 26, 2018

There is a new Pharo build available! The status of the build #809 was: SUCCESS. The Pull Request #1267 was integrated: "Move AuthorTest, SmalltalkImageTest, SystemDictionaryTest and other to package "System-Support-Tests"" Pull request url: https://github.com/pharo-project/pharo/pull/1267 Issue Url: https://pharo.fogbugz.com/f/cases/21797 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #808: 21792 SystemReporter code needs some love
by ci-pharo-ci-jenkins2＠inria.fr April 26, 2018

April 26, 2018

There is a new Pharo build available! The status of the build #808 was: SUCCESS. The Pull Request #1264 was integrated: "21792 SystemReporter code needs some love" Pull request url: https://github.com/pharo-project/pharo/pull/1264 Issue Url: https://pharo.fogbugz.com/f/cases/21792 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Fwd: asApproximateFraction[AtOrder:]
by Sean P. DeNigris April 25, 2018

April 25, 2018

Start of a thread on Squeak-Dev [1] (more discussion followed): Eliot Miranda-2 wrote > Hi All, > > asApproximateFraction isn't that useful. It is based on > asApproximateFractionAtOrder:, which gives you the best fraction it can > find up to order. e.g. > > testContinuedFractions > self assert: (Float pi asApproximateFractionAtOrder: 1) = (22/7). > self assert: (Float pi asApproximateFractionAtOrder: 3) = (355/113) > Here's 32-bit Float 1/3: > > ((FloatArray new: 1) at: 1 put: 1/3; at: 1) 0.3333333432674408 > > ((FloatArray new: 1) at: 1 put: 1/3; at: 1) asApproximateFraction > (11184811/33554432) > > That's not what I expected :-). The problem is that > asApproximateFractionAtOrder: is great if you know the number you're > dealing with, but if you don't then it'll give you too much information. > > [This value comes up in the vm parameters system report page, where 1/3 is > the ratio of growth to heap size above which a full GC is performed, i.e. > by default every time a scavenge causes the heap grows by 1/3 from the > last > time a full GC was performed, the system will do a full GC. It would be > great to report this as 1/3, not 0.33333298563957214, which is what's > emerging from the C code in the VM]. > > Let's get a feeling for orders; they're effectively negative powers of 10: > > (1 to: 20) collect: [:order| | f | > { order. (f := Float pi asApproximateFractionAtOrder: order). f asFloat. > (f > asFloat - Float pi) abs}] > {{1 . (22/7) . 3.142857142857143 . 0.0012644892673496777}. > {2 . (333/106) . 3.141509433962264 . 8.32196275291075e-5}. > {3 . (355/113) . 3.1415929203539825 . 2.667641894049666e-7}. > {4 . (103993/33102) . 3.1415926530119025 . 5.778906242426274e-10}. > {5 . (104348/33215) . 3.141592653921421 . 3.3162805834763276e-10}. > {6 . (208341/66317) . 3.1415926534674368 . 1.2235634727630895e-10}. > {7 . (312689/99532) . 3.1415926536189365 . 2.914335439641036e-11}. > {8 . (833719/265381) . 3.141592653581078 . 8.715250743307479e-12}. > {9 . (1146408/364913) . 3.141592653591404 . 1.6107115641261771e-12}. > {10 . (4272943/1360120) . 3.141592653589389 . 4.04121180963557e-13}. > {11 . (5419351/1725033) . 3.1415926535898153 . 2.220446049250313e-14}. > {12 . (80143857/25510582) . 3.1415926535897927 . 4.440892098500626e-16}. > {13 . (245850922/78256779) . 3.141592653589793 . 0.0}. > {14 . (817696623/260280919) . 3.141592653589793 . 0.0}. > {15 . (19052873251/6064717916) . 3.141592653589793 . 0.0}. > {16 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. > {17 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. > {18 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. > {19 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. > {20 . (19870569874/6324998835) . 3.141592653589793 . 0.0}} > > > More useful would be something like: > > asApproximateFractionToEpsilon: epsilon > "Answer a Fraction approximating the receiver. This conversion uses the > continued fraction method to approximate a floating point number." > > 1 to: 12 do: > [:order| | fraction | > fraction := self asApproximateFractionAtOrder: order. > (fraction - self) abs <= epsilon ifTrue: > [^fraction]]. > ^ self asApproximateFractionAtOrder: 0 > > and then instead of > > asApproximateFraction > "Answer a Fraction approximating the receiver. This conversion uses the > continued fraction method to approximate a floating point number." > > ^ self asApproximateFractionAtOrder: 0 > > one could have > > asApproximateFraction > "Answer a Fraction approximating the receiver. This conversion uses the > continued fraction method to approximate a floating point number." > > ^self asApproximateFractionToEpsilon: 1e-6 > > And hence > > { 0.0. 0.333. 0.5. 1.0. Float pi . ((FloatArray new: 1) at: 1 put: 1/3; > at: > 1) } collect: > [:n| n asApproximateFractionToEpsilon: 1e-6] > {0 . (333/1000) . (1/2) . 1 . (355/113) . (1/3)} > > Votes for or against changing asApproximateFraction to use > asApproximateFractionToEpsilon:? (asApproximateFraction has no senders > into > base image) > > Suggestions for a selector that would use self > asApproximateFractionToEpsilon: 1e-6 (less clumsy than e.g. > asUsefulApproximateFraction). > > _,,,^..^,,,_ > best, Eliot And then the proposed solution: Eliot Miranda-2 wrote > asApproximateFraction > "Answer a Fraction approximating the receiver. This conversion uses the > continued fraction method to approximate a floating point number." > > ^self asApproximateFractionToEpsilon: self abs / 1.0e6 > > â¦Seems to work well: > > > | them | > them := (1 to: 6) collect: [:po10| (1 / ((10 raisedTo: po10) * 3)) > asFloat]. > them collect: [:fraction| fraction asApproximateFractionToEpsilon: > fraction > / 1.0e6] {(1/30) . (1/300) . (1/3000) . (1/30000) . (1/300000) . > (1/3000000)} > > | them | > them := (1 to: 6) collect: [:po10| (1 / ((10 raisedTo: po10) / 3)) > asFloat]. > them collect: [:fraction| fraction asApproximateFractionToEpsilon: > fraction > / 1.0e6] > {(3/10) . (3/100) . (3/1000) . (3/10000) . (3/100000) . (3/1000000)} > > Float classPool associations > select: [:assoc| assoc value isFloat and: [assoc value isFinite and: > [assoc > value fractionPart ~= 0]]] > thenCollect: [:assoc| > assoc key -> (assoc value asApproximateFractionToEpsilon: assoc value / > 1.0e6)] {#Ln2->(1143/1649) . #Halfpi->(355/226) . #ThreePi->(1065/113) . > #RadiansPerDegree->(71/4068) . #Epsilon->(1/1000000000000) . > #MaxValLn->(16325/23) . #Ln10->(624/271) . #Pi->(355/113) . > #Sqrt2->(1393/985) . #Twopi->(710/113) . #E->(1264/465)} > > > So I'm for > > asApproximateFraction > "Answer a Fraction approximating the receiver. This conversion uses > the > continued fraction method to approximate a floating point number." > > ^self asApproximateFractionToEpsilon: (self / 1e6) abs > > talking in numerical analysis ignorance... > > -- > _,,,^..^,,,_ > best, Eliot 1. http://forum.world.st/asApproximateFraction-AtOrder-tp5074844.html ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

1 0

SortedCollection based on SortFunction [Re: SortedCollection>>reverse answers an inconsistent object]
by Denis Kudriashov April 25, 2018

April 25, 2018

Hi. Now we have really nice SortFunction's machinery. We can simply write: Object allSubclasses sorted: #name ascending instead of: Object allSubclasses sorted: [:a :b | a name <= b name ]. And there is special kind of SortFunction which represent such block itself: [:a :b | a name <= b name ] asSortFunction "==> a CollatorBlockFunction". The power of first class functions is that they provide reusable composition features like: contacts sorted: #name ascending, #surname descending. contacts sorted: (#name ascending, #surname descending) reversed. (look at class comments for more examples). It is all very cool and powerful but in the core Pharo still work with primitive blocks. All sorting methods and SortedCollection are implemented in terms of sortBlock. So SortFunction's are adopted to block interface #value:value:. And my proposal: Let's replace sortBlock by sortFunction everywhere. Block will still work but it will be converted to function. It will open new possibilities to implement more features. For example SortedCollection>>reversed would be trivial with sortFunction (see previous thread). Drawback is extra dependency in collections. But we can extract SortedCollection and related functions into separate package which probably will allow reduce bootstrapped codebase. I am not going to implement it right now. Just want to share this idea to see what's wrong with it. Best regards, Denis

2 2

[Pharo 7.0-dev] Build #807: 21763-TraitedMetaclass-should-empty-the-localMethods-and-baseLocalMethods-when-becoming-obsolete
by ci-pharo-ci-jenkins2＠inria.fr April 25, 2018

April 25, 2018

There is a new Pharo build available! The status of the build #807 was: SUCCESS. The Pull Request #1244 was integrated: "21763-TraitedMetaclass-should-empty-the-localMethods-and-baseLocalMethods-when-becoming-obsolete" Pull request url: https://github.com/pharo-project/pharo/pull/1244 Issue Url: https://pharo.fogbugz.com/f/cases/21763 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #806: 21773-update-iceberg-to-0-7-3
by ci-pharo-ci-jenkins2＠inria.fr April 25, 2018

April 25, 2018

There is a new Pharo build available! The status of the build #806 was: SUCCESS. The Pull Request #1251 was integrated: "21773-update-iceberg-to-0-7-3" Pull request url: https://github.com/pharo-project/pharo/pull/1251 Issue Url: https://pharo.fogbugz.com/f/cases/21773 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #805: 21777 Some assert:equal: and formatting cleanups in UFFI
by ci-pharo-ci-jenkins2＠inria.fr April 24, 2018

April 24, 2018

There is a new Pharo build available! The status of the build #805 was: SUCCESS. The Pull Request #1250 was integrated: "21777 Some assert:equal: and formatting cleanups in UFFI" Pull request url: https://github.com/pharo-project/pharo/pull/1250 Issue Url: https://pharo.fogbugz.com/f/cases/21777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

(no subject)
by Tristan Debrousse April 24, 2018

April 24, 2018

Hello, I am a student at UniversitÃ© de Bretagne Occidentale (Brest, France) and I just began an internship project of 6 weeks with Alain Plantec and Steven Costiou. The project involves the use of Pharo with Bloc to develop a GUI. -- Tristan

3 2

[Pharo 7.0-dev] Build #804: 21771-testInjectingExceptionHandlerFromProcessItself-is-unstable
by ci-pharo-ci-jenkins2＠inria.fr April 24, 2018

April 24, 2018

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

1 0