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

You can cheat in FFI as long as you don't get caught...
by Nicolas Cellier Nov. 9, 2017

Nov. 9, 2017

I was trying to inquire about my latest vm crash in libgit2 https://pharo.fogbugz.com/f/cases/20655/vm-crash-in-libgit-git_tree_free-th… when I found this bizarre prototype: ^ self callUnchecked: #(LGitReturnCodeEnum git_diff_tree_to_tree #(LGitDiff * diff , LGitRepository repo , LGitTree old_tree , LGitTree new_tree , LGitDiffOptions * opts)) options: #() While the libgit2 signature differs in indirection levels: https://libgit2.github.com/libgit2/#v0.19.0/group/diff/git_diff_tree_to_tree int git_diff_tree_to_tree(git_diff_list **diff, git_repository *repo, git_tree *old_tree, git_tree *new_tree, const git_diff_options *opts); The fact that it does not differs for opts, made me think of a bug... But no. opts is allocated on external c heap with: callUnchecked: #(LGitReturnCodeEnum git_diff_init_options(LGitDiffOptions * self, LGitOptionsVersionsEnum version)) int git_diff_init_options(git_diff_options *opts, unsigned int version); What you see this time is that signatures match... So the LGitDiffOptions handle will be an ExternalAddress that will really point on a git_diff_options In other words, the handle is a git_diff_options *... IOW, our LGitDiffOptions object points to an external it_diff_options so it is what it promises to be. For the other structures not so. We are lying on the level of indirection, so our LGitTree handle are not really a git_tree *. They are a git_tree **. (an ExternalAddress on a pointer). As long as we lie consistently, it's OK, because it avoids too much packToArity: unpackToArity: dance. That's the "beauty" of C pointers. We can cast them to whatever or pretend they are handle_for_anything * in the intermediate level, as long as original producer and final consumer agree on what it really points to. But from code quality perspective, it really stinks. Anyone like me opening a page to get the exact signature of the function will be scratching head and loose precious time. Especially when tracking vm crash down. I'm not sure how well it's documented, I presume it's a well known conscious hack from the original developpers, but such practice really ought to be discussed here.

3 6

[Pharo 7.0-dev] Build #277: 20582-atat-messages-call-errorKeyNotFound
by ci-pharo-ci-jenkins2＠inria.fr Nov. 9, 2017

Nov. 9, 2017

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

1 0

[Pharo 7.0-dev] Build #276: 20664-set-the-display-size-sooner
by ci-pharo-ci-jenkins2＠inria.fr Nov. 9, 2017

Nov. 9, 2017

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

1 0

[Pharo 7.0-dev] Build #275: 20499-Examples-in-GlamourPresentationModel-should-have-no-gtExamplePragma
by ci-pharo-ci-jenkins2＠inria.fr Nov. 9, 2017

Nov. 9, 2017

There is a new Pharo build available! The status of the build #275 was: SUCCESS. The Pull Request #455 was integrated: "20499-Examples-in-GlamourPresentationModel-should-have-no-gtExamplePragma" Pull request url: https://github.com/pharo-project/pharo/pull/455 Issue Url: https://pharo.fogbugz.com/f/cases/20499 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Zinc and Zodiac - Synching/Contributing
by Torsten Bergmann Nov. 9, 2017

Nov. 9, 2017

Hi Sven, for Zinc there is a new issue: 1. Zinc is using #asBytesDescription. It should not be used as it is deprecated https://github.com/pharo-project/pharo/pull/401 there is also 2. https://pharo.fogbugz.com/f/cases/20557 which is not yet integrated. I also proposed some simple but necessary cleanups for Zodiac in Pharo 7: 3. Proper categorization in Zodiac-Tests package - to use "test" category instead of "testing" and better group the tests written https://github.com/pharo-project/pharo/pull/355/files Also it looks like the #setUp in Zodiac tests never send a "super setUp". Which should be fixed too. I've noticed that both Zinc/Zodiac are not hosted on STHub. You seem to use your own custom hosting server on http://mc.stfx.eu/Zodiac http://mc.stfx.eu/ZincHTTPComponents as well as github: https://github.com/svenvc/zinc https://github.com/svenvc/zodiac If we just merge the changes from 3. into Pharo 7 they may later be overwritten when synching also Zodiac again as in 2. So how can we contribute from community side to both projects? Should I fork https://github.com/svenvc/zodiac and send a PR to it so that you can integrate? Thanks Torsten

6 8

[Pharo 7.0-dev] Build #274: 20662-displaying-method-versions-in-Nautilus-causes-DNU
by ci-pharo-ci-jenkins2＠inria.fr Nov. 9, 2017

Nov. 9, 2017

There is a new Pharo build available! The status of the build #274 was: SUCCESS. The Pull Request #457 was integrated: "20662-displaying-method-versions-in-Nautilus-causes-DNU" Pull request url: https://github.com/pharo-project/pharo/pull/457 Issue Url: https://pharo.fogbugz.com/f/cases/20662 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

about SortFunctions
by Nicolas Cellier Nov. 9, 2017

Nov. 9, 2017

Hi all, I started a discussion with Denis in a pull request https://github.com/pharo-project/pharo/pull/430 But since it's going beyond simple code review, it probably has a better place here. First, I want to say thanks for enriching this original work of Travis Griggs. http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html http://objology.blogspot.fr/2010/11/tag-sortfunctions.html <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> Of course, I'm never satisfied. So I don't really appreciate the rewrite of space ship operator <=> into a more heavy threeWayCompareTo: In my eyes, it's so obvious that <=> means < or = or > in the context of SortFunction And also that the order matches the signs < = > -1 0 1 IOW result will be -1 if receiver is <, 0 if equal, +1 if superior #threeWayCompareTo: does not tell as well. But maybe It's a question of taste and I don't have the same eyes as Pharo people? To me it's also a question of respect to the original author, don't change a good selector for the sake of changing. Apart this detail, I wanted to speak about SortByPropertyFunction. SortByProperty is super usefull for composing / chaining like this: population sortBy: #name ascending , #age descending. But currently, SortByPropertyFunction is allways using the default hardcoded collation <=> ... He he, it's also notice it's shorter to write ;) Imagine that my properties are neither String nor Magnitude, or they are, but I want a different collation policy, because in French $Ã© must not be sorted too far from $e. It could be written quite simply with: c sortBy: #name collatedInFrench ascending , #age descending With current implementation, collatedInFrench would have to use a block (thru a CollatorBlockFunction which is a proxy to the block in a SortFunction disguise): Symbol>>collatedInFrench "interpret self as a property" ^[:a :b | FrenchCollator collate: (self value: a) with: (self value: b)] But IMO SortByPropertyFunction should better feed a reified CollatorFunction, or said differently a SortFunction, as Denis said. Symbol>>collatedInFrench ^FrenchCollator new onProperty: self SortFunction>>onProperty: aValuable ^SortByPropertyFunction sortProperty: aValuable with: self What do you think? Nicolas

10 51

[Pharo 7.0-dev] Build #272: 20611-leftover-logCr-debug-logging-in-GLEmptyBrickarea
by ci-pharo-ci-jenkins2＠inria.fr Nov. 9, 2017

Nov. 9, 2017

There is a new Pharo build available! The status of the build #272 was: SUCCESS. The Pull Request #452 was integrated: "20611-leftover-logCr-debug-logging-in-GLEmptyBrickarea" Pull request url: https://github.com/pharo-project/pharo/pull/452 Issue Url: https://pharo.fogbugz.com/f/cases/20611 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Why 2017 sizeInMemory = 0?
by Denis Kudriashov Nov. 9, 2017

Nov. 9, 2017

Hi. Question from discord, why: 2017 sizeInMemory = 0 ? Looks like a bug, but maybe there is some reason for this.

3 3

[Pharo 7.0-dev] Build #271: 20657-Command-B-in-playground-does-not-work-the-save-way-as-printit
by ci-pharo-ci-jenkins2＠inria.fr Nov. 9, 2017

Nov. 9, 2017

There is a new Pharo build available! The status of the build #271 was: SUCCESS. The Pull Request #450 was integrated: "20657-Command-B-in-playground-does-not-work-the-save-way-as-printit" Pull request url: https://github.com/pharo-project/pharo/pull/450 Issue Url: https://pharo.fogbugz.com/f/cases/20657 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0