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

[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

[Ann] Iceberg 0.7.3

by Guillermo Polito

Hi all, We just introduced Iceberg 0.7.3 into Pharo. This new version solves several issues people had when contributing to Pharo in general and others. I've made a screencast on how to contribute to Pharo, and added some tutorial and glossary in Iceberg's wiki. Below the links and the changes log. Thanks for making your issue reports ^^. We will schedule a backporting to Pharo6.1 in a couple of weeks, once we have another iteration. Cheers, Guille # Contribute to Pharo with Iceberg 0.7.3 - wiki page: https://github.com/pharo-vcs/iceberg/wiki/Contribute-to-Pharo-with-Iceberg-… - Screencast: https://www.youtube.com/watch?v=PK2yCu2rWCc&feature=youtu.because This screencast shows how to use Iceberg 0.7.3 to contribute to latest Pharo 7, by cloning from scratch your own (potentially outdated) clone. This video will guide you through: - solve the "Missing local repository" by cloning - solve the "Fetch required" that appears because the fork is out of date - solve the "Detached working copy" by creating a new branch - use the pharo plugin to create an issue branch - make some changes, commit them and push them to your fork - make a pull request If you already have a clone, you can just import an existing repository from your disk. The rest of the instructions should be the same. If you don't have a fork, create one before doing anything else. New videos to come with more explanations. # Iceberg Glossary https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary # 0.7.3 ChangesLog - #693 <https://github.com/pharo-vcs/iceberg/pull/693>: fixing problem when the announcement of changes in a package is nil. (bug, important) - #682 <https://github.com/pharo-vcs/iceberg/issues/682>: update update script (Pharo6-backport) - #681 <https://github.com/pharo-vcs/iceberg/issues/681>: Author name is not correctly decoded (UI, enhancement) - #680 <https://github.com/pharo-vcs/iceberg/issues/680>: Repair actions dialog should explain the situation (UI, enhancement, important) - #679 <https://github.com/pharo-vcs/iceberg/issues/679>: Create branch repair action should show create branch from issue if available (Pharo plugin, UI) - #678 <https://github.com/pharo-vcs/iceberg/issues/678>: Iceberg does not correctly recognize packages (bug, important) - #677 <https://github.com/pharo-vcs/iceberg/issues/677>: Unknown commit can only be solved with repair action (Model, bug, important) - #676 <https://github.com/pharo-vcs/iceberg/issues/676>: Unknown commit state is not properly shown (UI, bug, important) - #667 <https://github.com/pharo-vcs/iceberg/issues/667>: Merging branches with file deletion doesn't seem possible (bug, important, merge) - #666 <https://github.com/pharo-vcs/iceberg/issues/666>: Iceberg sometimes add a $ to commit message (Model, bug) - #662 <https://github.com/pharo-vcs/iceberg/issues/662>: The Pharo plugin has to do the fetch only if required. (Pharo plugin, enhancement) - #660 <https://github.com/pharo-vcs/iceberg/pull/660>: Add a star badge in the push button in case of a new branch () - #658 <https://github.com/pharo-vcs/iceberg/issues/658>: Progress Bar during checkout of Repository. (UI, enhancement) - #657 <https://github.com/pharo-vcs/iceberg/issues/657>: Confusing UI: Ghost Test maybe should be default? (UI, enhancement) - #656 <https://github.com/pharo-vcs/iceberg/issues/656>: Typo in Progress Bar (UI, bug) - #651 <https://github.com/pharo-vcs/iceberg/issues/651>: When pushing a new branch the list of commit is empty (UI, bug) - #650 <https://github.com/pharo-vcs/iceberg/issues/650>: "Create new branch from issue" is leaving image in detached working copy state () - #649 <https://github.com/pharo-vcs/iceberg/issues/649>: The VM is crashing when trying to use Iceberg from a saved image (bug) - #645 <https://github.com/pharo-vcs/iceberg/issues/645>: IceLibgitRepository should use "utilities" protocol instead of "utils" (clean up) - #644 <https://github.com/pharo-vcs/iceberg/issues/644>: Unnecessary temp in IceTipGitHubRepositoryPanel>>#getGitHubRepository" (clean up) - #643 <https://github.com/pharo-vcs/iceberg/issues/643>: LGit_GIT_ERROR: error authenticating: no auth sock variable loading a Tonel based baseline dependency in smalltalkCI (bug, important) - #639 <https://github.com/pharo-vcs/iceberg/issues/639>: Create pull request fails if branch has not been pushed (Github plugin, bug) - #636 <https://github.com/pharo-vcs/iceberg/issues/636>: The pull button should have a star badge when it has no upstream (UI, enhancement, important) - #634 <https://github.com/pharo-vcs/iceberg/issues/634>: Travis is not building Pull Requests (CI, bug, important) - #624 <https://github.com/pharo-vcs/iceberg/issues/624>: add "add remote" to remote picking on pull/push browsers (enhancement) - #610 <https://github.com/pharo-vcs/iceberg/pull/610>: Fix for issue #608 <https://github.com/pharo-vcs/iceberg/issues/608> and #607 <https://github.com/pharo-vcs/iceberg/issues/607>. (clean up) - #609 <https://github.com/pharo-vcs/iceberg/issues/609>: New branch repair action does not refresh dirty packages (UI, bug) - #583 <https://github.com/pharo-vcs/iceberg/issues/583>: Creating a tonel project does not commit the properties file (Model, bug) - #542 <https://github.com/pharo-vcs/iceberg/issues/542>: Bug during commit of a new package (Model, bug) -- 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 25, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Sean P. DeNigris

Thierry Goubier wrote > If using a baseline in the Catalog forces it to be more complexâ¦ I didn't think we were discussing changing baselines themselves, just a better adapter layer than hand-edited Configs Thierry Goubier wrote > A typical git-based development is one tag or branch per pharo > version, hence one BaselineOf per supported Pharo version. Hmm, I didn't know that. I have not been using that workflow, but '*-PlatformPharo60' packages. I wonder what the tradeoffs areâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 24, 2018

[Pharo 7.0-dev] Build #805: 21777 Some assert:equal: and formatting cleanups in UFFI

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

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…

April 24, 2018