- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Is Beacon still planned to be added to P7?

by Guillermo Polito

On Mon, Apr 23, 2018 at 1:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I hope so. Beacon is ready to be integrated, but I do not know if there is > enough bandwidth right now due to the Iceberg work. > Well, if people issue a pull request I'll gladly review it. Guille > > Doru > > > On Apr 23, 2018, at 1:08 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > 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 > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 26, 2018

Re: [Pharo-dev] Fwd: ByteArray>>at:put:

by Sven Van Caekenberghe

> On 26 Apr 2018, at 15:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Relevant to Pharo? > > From http://forum.world.st/ByteArray-at-put-tp4955848.html : We don't (want to) mix binary and character collections or streams. Going from one to the other is called encoding and decoding, it has to be done while being conscious of which encoding you are using. Sending #asByteArray to a String or #asString to a ByteArray is dangerous, lazy and wrong (in most cases), especially in an international context. > 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 >

April 26, 2018

Fwd: ByteArray>>at:put:

by Sean P. DeNigris

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

April 26, 2018

[Pharo 7.0-dev] Build #808: 21792 SystemReporter code needs some love

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

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…

April 26, 2018

Fwd: asApproximateFraction[AtOrder:]

by Sean P. DeNigris

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

April 25, 2018

Re: [Pharo-dev] SortedCollection based on SortFunction [Re: SortedCollection>>reverse answers an inconsistent object]

by Denis Kudriashov

2018-04-25 14:57 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > I think sortfunctions are a great tool, with particular benefits if you > use it in the context of metamodels, like with Magritte descriptions. > > Also I think it is more readable to use symbols/sortfunctions than blocks. > > The only thing that should be guarded in the use of SortFunctions is the > handling of nil, a comparison with a nil object should fail noisily, > which currently doesn't by default AFAIR (I added the option to put nils > first or last in the resulting collection). > > Note: Being myself an stubborn early optimizer I would make that > `SortedCollection new` returns a sorted collection with itself as the > default sortblock implementing #value:value: in SortedCollection. This > saves you from instantiating new objects other than the collection > itself for instances where sortblock is based on #<= as it currently is. > +1 for default function in collection. But I don't like solution. We have DefaultSortFunction for this. Only missing part is singleton instance: SortedCollection>>new ^self sortBlock: DefaultSortFunction instance > > Regards, > > > On 25/04/2018 09:08, Denis Kudriashov wrote: > > 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 > > -- > Esteban A. Maringolo > >

April 25, 2018

Re: [Pharo-dev] SortedCollection based on SortFunction [Re: SortedCollection>>reverse answers an inconsistent object]

by Esteban A. Maringolo

I think sortfunctions are a great tool, with particular benefits if you use it in the context of metamodels, like with Magritte descriptions. Also I think it is more readable to use symbols/sortfunctions than blocks. The only thing that should be guarded in the use of SortFunctions is the handling of nil, a comparison with a nil object should fail noisily, which currently doesn't by default AFAIR (I added the option to put nils first or last in the resulting collection). Note: Being myself an stubborn early optimizer I would make that `SortedCollection new` returns a sorted collection with itself as the default sortblock implementing #value:value: in SortedCollection. This saves you from instantiating new objects other than the collection itself for instances where sortblock is based on #<= as it currently is. Regards, On 25/04/2018 09:08, Denis Kudriashov wrote: > 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 -- Esteban A. Maringolo

April 25, 2018

SortedCollection based on SortFunction [Re: SortedCollection>>reverse answers an inconsistent object]

by Denis Kudriashov

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

April 25, 2018

[Pharo 7.0-dev] Build #807: 21763-TraitedMetaclass-should-empty-the-localMethods-and-baseLocalMethods-when-becoming-obsolete

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

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…

April 25, 2018

[Pharo 7.0-dev] Build #806: 21773-update-iceberg-to-0-7-3

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

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…

April 25, 2018