Smalltalk › Squeak › Squeak - Dev

Can we please fix the IDE?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Chris Muller-3

Can we please fix the IDE?

Hey Colin, something with Environments has had a basic IDE function
broken for some time now. Trunk broken for long time can affect the
community, could you help me get this fixed?

First, the problem can be observed simply by browsing references to
the class Error, first from workspace text then from a class list.
The root cause is that these use different ways to find the list of
referencing methods. One uses:

(SystemNavigation default allCallsOn: (Smalltalk globals
associationAt: #Error))

while the other uses:

(SystemNavigation default allCallsOn: (Smalltalk globals bindingOf: #Error))

The two expressions (bindingOf: vs. associationAt:) produce
equivalent, but not identical ClassBindings. But since
CompiledMethod>>#indexOfLiteral: is doing an identity-check on the
ClassBinding #Error=>Error, it comes back false for the
#associationAt: case.

So, what is the proper fix here? 1) make bindingOf: and
associationAt: point to the same object? 2) change
CompiledMethod>>#indexOfLiteral: to do an equality rather than
identity check? 3) change the IDE code to use #bindingOf: instead of
#associationAt:?

I've already been affected by this and would like to get it fixed,
please advise.

Thanks,
Chris

Colin Putney-3

Re: Can we please fix the IDE?

On Sun, Apr 28, 2013 at 10:00 AM, Chris Muller <[hidden email]> wrote:

First, the problem can be observed simply by browsing references to
the class Error, first from workspace text then from a class list.
The root cause is that these use different ways to find the list of
referencing methods. One uses:

So, what is the proper fix here? 1) make bindingOf: and
associationAt: point to the same object? 2) change
CompiledMethod>>#indexOfLiteral: to do an equality rather than
identity check? 3) change the IDE code to use #bindingOf: instead of
#associationAt:?

The proper fix is #3 - since compiling a method uses #bindingOf: searching for bindings should do the same.

I'll submit a fix shortly.

Colin

Eliot Miranda-2

Re: Can we please fix the IDE?

On Sun, Apr 28, 2013 at 10:31 AM, Colin Putney <[hidden email]> wrote:

On Sun, Apr 28, 2013 at 10:00 AM, Chris Muller <[hidden email]> wrote:

First, the problem can be observed simply by browsing references to
the class Error, first from workspace text then from a class list.
The root cause is that these use different ways to find the list of
referencing methods. One uses:

So, what is the proper fix here? 1) make bindingOf: and
associationAt: point to the same object? 2) change
CompiledMethod>>#indexOfLiteral: to do an equality rather than
identity check? 3) change the IDE code to use #bindingOf: instead of
#associationAt:?

The proper fix is #3 - since compiling a method uses #bindingOf: searching for bindings should do the same.

I don't understand how #3 fixes things. If one has an alias to e.g. Error then all calls on Error should include references to the alias right? So doesn't there need to be some clever code for literalEqual: so that ALiases dereference to get the actual binding?

I'll submit a fix shortly.

Colin

--
best,

Eliot

Colin Putney-3

Re: Can we please fix the IDE?

On Mon, Apr 29, 2013 at 3:57 PM, Eliot Miranda <[hidden email]> wrote:

I don't understand how #3 fixes things. If one has an alias to e.g. Error then all calls on Error should include references to the alias right? So doesn't there need to be some clever code for literalEqual: so that ALiases dereference to get the actual binding?

Yeah, #3 is a partial fix.

We should definitely use #bindingOf: for comparing with bindings in a CompiledMethod, because that's what the Compiler uses to create those bindings in the first place. Some of the other changes I've made in the past few days have the effect of only using Aliases when necessary—that is, when we're referring to a class or global by a different name from the one it was declared with. Between that and Environment>>recompileAll, we should have correct behaviour for the single-environment case that exists in the trunk at the moment.

For the multi-environment cases, we'll need to handle Aliases correctly, and I guess you're right about #literalEqual:.

Colin