log-ci-beta@lists.pharo.org

log-ci related messages when beta testing.

View all threads

[Pharo PR 7358] Build #1: FAILURE

CP
ci-pharo-ci-jenkins2@inria.fr
Thu, Sep 24, 2020 8:10 AM

There is a new Pharo build available!

The status of the build #1 was: FAILURE.

Could not extract further issue information from commit message: The compiler compiles always for an enviorment (normally the global one).

When you compile for another environment, there is one big question: Do we ignore the environment set by the classes inside of the environment?

The current implementation does that: the Scope hierarchy is a parallel hierarchy. That is we have classScope->environment. All lookup is carefully implemented to use that, not the environment of the class.

Problems:

  • This is a lot of machineary to support something strange.
  • #hasBindingThatBeginsWith: is out of sync with #bindingsOf: (as it does not know the outer environment that the compiler used)
  • The environment that we set in the compiler is not at all reflected in the static entitie used.  That is, there is no way to implement #scope for instance variables
  • #scope for Class Variables is already the class, not the (not persistet) compiler internal scope

If we add two contraints:

  1. Envionment of classes in SystemDictionary instance has to to be that instance
  2. Lookup starts for the class that we compile for even for globals

Then we can just remove the concept that the compiler has an additonal scope. The scope of a class it the class, it's outerScope is the environment of the class.

We have right now no use cases that use the current complex scheme... it was used for tests, but that can be replaced by #bindings:.

But I wonder if there are use cases.
Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-7358/1/

There is a new Pharo build available! The status of the build #1 was: FAILURE. Could not extract further issue information from commit message: The compiler compiles always for an enviorment (normally the global one). When you compile for another environment, there is one big question: Do we ignore the environment set by the classes inside of the environment? The current implementation does that: the Scope hierarchy is a parallel hierarchy. That is we have classScope->environment. All lookup is carefully implemented to use that, not the environment of the class. Problems: - This is a lot of machineary to support something strange. - #hasBindingThatBeginsWith: is out of sync with #bindingsOf: (as it does not know the outer environment that the compiler used) - The environment that we set in the compiler is not at all reflected in the static entitie used. That is, there is no way to implement #scope for instance variables - #scope for Class Variables is already the class, not the (not persistet) compiler internal scope If we add two contraints: 1. Envionment of classes in SystemDictionary instance has to to be that instance 2. Lookup starts for the class that we compile for even for globals Then we can just remove the concept that the compiler has an additonal scope. The scope of a class it the class, it's outerScope is the environment of the class. We have right now no use cases that use the current complex scheme... it was used for tests, but that can be replaced by #bindings:. But I wonder if there are use cases. Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-7358/1/