September 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #757: Opal-clean-lookUpVar

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

There is a new Pharo build available! The status of the build #757 was: FAILURE. The Pull Request #4656 was integrated: "Opal-clean-lookUpVar" Pull request url: https://github.com/pharo-project/pharo/pull/4656 Issue Url: https://github.com/pharo-project/pharo/issues/Opal Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 20, 2019

[Pharo 8.0] Build #756: Remove-nil-initialization-from-initialize-methods

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

There is a new Pharo build available! The status of the build #756 was: FAILURE. The Pull Request #4657 was integrated: "Remove-nil-initialization-from-initialize-methods" Pull request url: https://github.com/pharo-project/pharo/pull/4657 Issue Url: https://github.com/pharo-project/pharo/issues/Remove Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2019

[Pharo 8.0] Build #755: new code of conduct approved by the Board

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

There is a new Pharo build available! The status of the build #755 was: FAILURE. The Pull Request #4660 was integrated: "new code of conduct approved by the Board" Pull request url: https://github.com/pharo-project/pharo/pull/4660 Issue Url: https://github.com/pharo-project/pharo/issues/Pharo8.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2019

[Pharo 8.0] Build #754: DebuggerMethodMap: use #tempNames

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

There is a new Pharo build available! The status of the build #754 was: FAILURE. The Pull Request #4659 was integrated: "DebuggerMethodMap: use #tempNames" Pull request url: https://github.com/pharo-project/pharo/pull/4659 Issue Url: https://github.com/pharo-project/pharo/issues/DebuggerMethodMap Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2019

[Pharo 8.0] Build #753: 2845-Error-in-CollectionflatCollect-b-as-String

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

There is a new Pharo build available! The status of the build #753 was: SUCCESS. The Pull Request #4594 was integrated: "2845-Error-in-CollectionflatCollect-b-as-String" Pull request url: https://github.com/pharo-project/pharo/pull/4594 Issue Url: https://github.com/pharo-project/pharo/issues/2845 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2019

[Pharo 8.0] Build #752: 2594-Add-a-way-to-browse-the-cursors-in-an-inspector

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

There is a new Pharo build available! The status of the build #752 was: FAILURE. The Pull Request #4649 was integrated: "2594-Add-a-way-to-browse-the-cursors-in-an-inspector" Pull request url: https://github.com/pharo-project/pharo/pull/4649 Issue Url: https://github.com/pharo-project/pharo/issues/2594 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2019

Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?

by Denis Kudriashov

Hi Guille. ÑÑ, 18 ÑÐµÐ½Ñ. 2019 Ð³. Ð² 14:22, Guillermo Polito <guillermopolito(a)gmail.com>: > Tools should work against #localMethods and #origin, which hide how the > actual implementation stores the things :). > I am a bit confused by this sentence. My original design of scopes was purely based on #localMethods and #origin to follow this idea. We had long dispute with Esteban about my approach and I remember you and Pablo also supported Esteban opinion. At the end he changed the implementation to use #methods and #methodClass instead. But it was not completely finished and therefore there are still some bugs like this one. So did you change the opinion or do I misunderstand your point? > We already had in the past a lot of tools that hardcoded/duplicated the > internals of Traits for example. > > The other advantage of this is that, imagine you want to extend Pharo > with: > - multimethods => localMethods will have a single multi-method > implementation, and the implementation side will contain maybe an expanded > version with type checks or even one method per type combination > - optional parameters => a single method with many parameters should be > expanded to many methods with less parameters + default values > > The idea is that tools do not hardcode the implementation details of these > extensions, so the public API is #localMethods and #origin :) > Of course, one could design a tool showing #methods, which will show the > low-level view of classes. > > > > Moreover, (Iâm confirming this with Pablo on line right now) the local > methods dictionary should be just a subset of the method dictionary. > In other words, the invariant is that methods in localMethods should be > included in the methoddict, they should not differ as they are differing > there. > > 2nd bug) UFFI? seems to be messing with this invariant :) > > When a UFFI binding is executed for the very first time, the ffi call > definition gets compiled and a new compiled method is generated performing > that call. > When a session finishes (the image stops/restarts) ffi bindings are reset > (because their compilation is platform dependent). > > What we are seeing there is that somehow UFFI managed to reset a binding > method and put a wrong one in the local method > > Iâve seen this bug before but never got the insight of what was producing > it (neither put too much time to dig on it either :P). > Another possibility is that the culprit are the LibGit bindings, which > extend UFFI binding compilation. > > > I haven't looked at this, but what I saw was the localMethods was > correct and the methodDict was old: > > Redefine a base system method (LGitCommit>>commit_author:) using an > extension method resulted in methodDict containing the original > definition and the localMethods containing the overridden method. > What I would expect is that the overridden method is what is used > everywhere. > > I'm not sure if this is related to UFFI or not. > > > Pablo tracked this down to possibly > > FFIMethodRegistry >> removeMethod: aMethod > > aMethod methodClass methodDict > at: aMethod selector > put: (aMethod propertyValueAt: #ffiNonCompiledMethod) >

Sept. 18, 2019

[Pharo 8.0] Build #751: 4644-ASTtoIRMappingTests---ASTtoIRMappingTest

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

There is a new Pharo build available! The status of the build #751 was: FAILURE. The Pull Request #4646 was integrated: "4644-ASTtoIRMappingTests---ASTtoIRMappingTest" Pull request url: https://github.com/pharo-project/pharo/pull/4646 Issue Url: https://github.com/pharo-project/pharo/issues/4644 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 18, 2019

Re: [Pharo-dev] Iceberg Error in Pharo 7

by Sean P. DeNigris

Sean P. DeNigris wrote > somehow the PackageSet got out of sync This was also the cause of the problem I reported on Discord where changes were not showing up in Iceberg. I create an issue: RPackageSet Out of Sync https://github.com/pharo-project/pharo/issues/4648 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 18, 2019

Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?

by Alistair Grant

Hi Guille, On Wed, 18 Sep 2019 at 15:22, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > El 18 sept 2019, a las 15:05, Alistair Grant <akgrant0710(a)gmail.com> escribiÃ³: > > > [snip/] > > From what you've written above (and below), the two dictionaries > should always have the same instance of CompiledMethod so it shouldn't > matter where it comes from. > > > Just for the record, yes and no :). > > With the new trait implementation, we have actually a modular MOP. > All classes (whether traited or not) understand: > - #localMethods => returning the methods as they are implemented in the class > - #methods => returning the actual methods executed by the VM > > For normal classes, #localMethods is defined as follows: > > localMethods > ^ self methods > > And methods understand > - #origin => where that method is actually defined > For example, in a traited class a lookup should be done in the trait composition, otherwise is the class where the method is installed. > > Tools should work against #localMethods and #origin, which hide how the actual implementation stores the things :). > We already had in the past a lot of tools that hardcoded/duplicated the internals of Traits for example. > > The other advantage of this is that, imagine you want to extend Pharo with: > - multimethods => localMethods will have a single multi-method implementation, and the implementation side will contain maybe an expanded version with type checks or even one method per type combination > - optional parameters => a single method with many parameters should be expanded to many methods with less parameters + default values > > The idea is that tools do not hardcode the implementation details of these extensions, so the public API is #localMethods and #origin :) > Of course, one could design a tool showing #methods, which will show the low-level view of classes. Thanks for the clarification, that makes sense and will help with tracking this further. > > I haven't looked at this, but what I saw was the localMethods was > > correct and the methodDict was old: > > > > Redefine a base system method (LGitCommit>>commit_author:) using an > > extension method resulted in methodDict containing the original > > definition and the localMethods containing the overridden method. > > What I would expect is that the overridden method is what is used > > everywhere. > > > > I'm not sure if this is related to UFFI or not. > > > Pablo tracked this down to possibly > > FFIMethodRegistry >> removeMethod: aMethod > > aMethod methodClass methodDict > at: aMethod selector > put: (aMethod propertyValueAt: #ffiNonCompiledMethod) That does look bad :-) Using the test class included below: MethodDictionaryConsistencyTest new inconsistentMethodDefinitions answers a collection of 240 methods where methodDict and localMethods aren't the same instance. All of the methods class names begin with 'LGit' :-) There may still be one more bug involved since the scenario I mentioned above regarding Iceberg and extension methods doesn't seem to fit the FFI description (it calls an ffi method, but isn't one itself). Thanks, Alistair

Sept. 18, 2019