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

[Pharo 7.0-dev] Build #812: 21789 Better tagging in Collections-Native
by ci-pharo-ci-jenkins2＠inria.fr April 27, 2018

April 27, 2018

There is a new Pharo build available! The status of the build #812 was: SUCCESS. The Pull Request #1262 was integrated: "21789 Better tagging in Collections-Native" Pull request url: https://github.com/pharo-project/pharo/pull/1262 Issue Url: https://pharo.fogbugz.com/f/cases/21789 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

libfreetype6 missing in the dependencies of ubuntu Pharo distribution
by Peter UhnÃ¡k April 27, 2018

April 27, 2018

Hi, I've just tried installing pharo from package manager on Elementary OS, which is a ubuntu derivative. All went well, except fonts weren't working in 32 bit version, and I had to install by hand "libfreetype6:i386" ... is it missing in the dependencies? Thanks, Peter

2 4

[Pharo 7.0-dev] Build #811: 21788 Cleanup Athens-Examples
by ci-pharo-ci-jenkins2＠inria.fr April 27, 2018

April 27, 2018

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

1 0

Fwd: ByteArray>>at:put:
by Sean P. DeNigris April 26, 2018

April 26, 2018

Relevant to Pharo? >From http://forum.world.st/ByteArray-at-put-tp4955848.html : Bert Freudenberg wrote > On 26 April 2018 at 11:28, marcel.taeumel < > Marcel.Taeumel@ > > wrote: > >> Hi, there. >> >> I cannot put a ByteString into a ByteArray via a WriteStream anymore: >> >> | s | >> s := WriteStream on: ByteArray new. >> s nextPutAll: 'hello'. >> >> You need to do: >> >> | s | >> s := WriteStream on: ByteArray new. >> s nextPutAll: 'hello' asByteArray. >> >> This breaks code. >> >> Best, >> Marcel >> > > âTechânically this is an expected error - you simply cannot put Characters > (the elements of a String) into a ByteArray. However, for convenience we > do > support copying Strings into ByteArrays in various places, including > WriteStream>>nextPutAll:. > > However, the test in WriteStream>>nextPutAll: is too strict. It needs to > be > "collection class isBits" instead of "collection isString". This makes the > code actually match its comment: > > WriteStream>>nextPutAll: aCollection > > | newEnd | > (collection class == aCollection class > or: [ collection class isBits > and: [ aCollection isString > and: [ collection class format = aCollection class format ] ] ]) "Let > Strings with the same field size as collection take the quick route too." > ifFalse: [ ^ super nextPutAll: aCollection ]. > > newEnd := position + aCollection size. > newEnd > writeLimit ifTrue: > [self growTo: newEnd + 10]. > > collection replaceFrom: position+1 to: newEnd with: aCollection > startingAt: 1. > position := newEnd. > ^aCollectionâ > > With that change your example works. I think this was the original intent > of the code. > > Fixed in Collections-bf.787 > > - Bert - ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

3 3

Is Beacon still planned to be added to P7?
by Peter UhnÃ¡k April 26, 2018

April 26, 2018

Hi, in several older discussions there was a mention of Beacon logger being added to Pharo 7 (by default)... is that still the plan? Thanks, Peter

6 5

[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