The Inbox: System-jr.948.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: System-jr.948.mcz

commits-2
A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-jr.948.mcz

==================== Summary ====================

Name: System-jr.948
Author: jr
Time: 5 May 2017, 12:08:58.857884 am
UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
Ancestors: System-ul.947

incorporate behaviors from other environments in allBehaviorsDo:

This enables senders/implementors and method searches across environments.

=============== Diff against System-ul.947 ===============

Item was changed:
  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
  allBehaviorsDo: aBlock
  "Evaluate the argument, aBlock, for each kind of Behavior in the system
  (that is, Object and its subclasses and Traits).
  ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
  behaviors for which the following should be executed:
 
  Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].
 
  but what follows is way faster than enumerating all objects."
 
+ Environment allInstancesDo: [:environment |
+ environment allClassesAndTraitsDo: [ :class |
+ aBlock value: class.
+ class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
+ aBlock value: class class ] ] ]!
- self environment allClassesAndTraitsDo: [ :class |
- aBlock value: class.
- class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
- aBlock value: class class ] ]!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Jakob Reschke
2017-05-16 19:09 GMT+02:00 [hidden email]
<[hidden email]>:
> class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"

Is this comment from a time before ClassTrait, or does it have
something else im mind?

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Levente Uzonyi
On Tue, 16 May 2017, Jakob Reschke wrote:

> 2017-05-16 19:09 GMT+02:00 [hidden email]
> <[hidden email]>:
>> class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
>
> Is this comment from a time before ClassTrait, or does it have
> something else im mind?

Remove traits => problem solved. :)

Levente

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Levente Uzonyi
In reply to this post by commits-2
On Tue, 16 May 2017, [hidden email] wrote:

> A new version of System was added to project The Inbox:
> http://source.squeak.org/inbox/System-jr.948.mcz
>
> ==================== Summary ====================
>
> Name: System-jr.948
> Author: jr
> Time: 5 May 2017, 12:08:58.857884 am
> UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
> Ancestors: System-ul.947
>
> incorporate behaviors from other environments in allBehaviorsDo:
>
> This enables senders/implementors and method searches across environments.

Wasn't the idea to have each environment its own SystemNavigation?
This change would break that.

Levente

>
> =============== Diff against System-ul.947 ===============
>
> Item was changed:
>  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
>  allBehaviorsDo: aBlock
>   "Evaluate the argument, aBlock, for each kind of Behavior in the system
>   (that is, Object and its subclasses and Traits).
>   ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
>   behaviors for which the following should be executed:
>
>   Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].
>
>   but what follows is way faster than enumerating all objects."
>
> + Environment allInstancesDo: [:environment |
> + environment allClassesAndTraitsDo: [ :class |
> + aBlock value: class.
> + class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
> + aBlock value: class class ] ] ]!
> - self environment allClassesAndTraitsDo: [ :class |
> - aBlock value: class.
> - class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
> - aBlock value: class class ] ]!

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Eliot Miranda-2
In reply to this post by commits-2
Hi Jakob,



On Tue, May 16, 2017 at 10:09 AM, <[hidden email]> wrote:
A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-jr.948.mcz

==================== Summary ====================

Name: System-jr.948
Author: jr
Time: 5 May 2017, 12:08:58.857884 am
UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
Ancestors: System-ul.947

incorporate behaviors from other environments in allBehaviorsDo:

This enables senders/implementors and method searches across environments.

=============== Diff against System-ul.947 ===============

Item was changed:
  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
  allBehaviorsDo: aBlock
        "Evaluate the argument, aBlock, for each kind of Behavior in the system
        (that is, Object and its subclasses and Traits).
        ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
        behaviors for which the following should be executed:

                Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].

        but what follows is way faster than enumerating all objects."

+       Environment allInstancesDo: [:environment |
+               environment allClassesAndTraitsDo: [ :class |
+                       aBlock value: class.
+                       class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
+                               aBlock value: class class ] ] ]!
-       self environment allClassesAndTraitsDo: [ :class |
-               aBlock value: class.
-               class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
-                       aBlock value: class class ] ]!

Forgive me for being blunt but Environment allInstancesDo: is absurd and unacceptable.  Environments *must* build some kind of graph that can be enumerated without recourse to a hammer like allInstancesDo:.  This simply doesn't scale.  And it suffers the problem of enumerating environments that are no longer in use but have yet to be garbage collected.  Please roll back this change and take a better approach.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Jakob Reschke
In reply to this post by commits-2
Hi,

I almost expected this feedback regarding allInstances ;-) If the change is still only in the Inbox, no harm should have been done, otherwise somebody else should revert it in trunk.

An alternative would be to enumerate only the Environments registered in that class pool variable. It requires everyone to use the correct "constructor" though, when the Environment is set up.

For the sake of learning some more: I have plenty of garbage environments in my image (due to test cases creating them and references I will have to track down at another time), but the allInstancesDo does not remarkably slow down the navigation features for me. Which cases do you have in mind when you say that it does not scale?

Best,
Jakob

Am 16.05.2017 23:21 schrieb "Eliot Miranda" <[hidden email]>:
Hi Jakob,



On Tue, May 16, 2017 at 10:09 AM, <[hidden email]> wrote:
A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-jr.948.mcz

==================== Summary ====================

Name: System-jr.948
Author: jr
Time: 5 May 2017, 12:08:58.857884 am
UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
Ancestors: System-ul.947

incorporate behaviors from other environments in allBehaviorsDo:

This enables senders/implementors and method searches across environments.

=============== Diff against System-ul.947 ===============

Item was changed:
  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
  allBehaviorsDo: aBlock
        "Evaluate the argument, aBlock, for each kind of Behavior in the system
        (that is, Object and its subclasses and Traits).
        ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
        behaviors for which the following should be executed:

                Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].

        but what follows is way faster than enumerating all objects."

+       Environment allInstancesDo: [:environment |
+               environment allClassesAndTraitsDo: [ :class |
+                       aBlock value: class.
+                       class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
+                               aBlock value: class class ] ] ]!
-       self environment allClassesAndTraitsDo: [ :class |
-               aBlock value: class.
-               class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
-                       aBlock value: class class ] ]!

Forgive me for being blunt but Environment allInstancesDo: is absurd and unacceptable.  Environments *must* build some kind of graph that can be enumerated without recourse to a hammer like allInstancesDo:.  This simply doesn't scale.  And it suffers the problem of enumerating environments that are no longer in use but have yet to be garbage collected.  Please roll back this change and take a better approach.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Jakob Reschke
In reply to this post by commits-2
Hi Levente,

In my previous patches I gave each SystemNavigation an environment in order to get it working inside another environment at all, as a first step. It might not be the best solution however, but rather an initial workaround, as I find the navigation stuff more practical when it looks into all the available environments instead of only the one I am currently browsing. After all, it is still called SystemNavigation and not EnvironmentNavigation.

More specific navigation scoping like ENVY provides it for its packages ("Senders in dependent Applications" etc.) might be nice, but more work.

When I find the time, I can look if the environment specificness of SystemNavigation can and should be dropped again.

Best,
Jakob

Am 16.05.2017 23:20 schrieb "Levente Uzonyi" <[hidden email]>:
On Tue, 16 May 2017, [hidden email] wrote:

> A new version of System was added to project The Inbox:
> http://source.squeak.org/inbox/System-jr.948.mcz
>
> ==================== Summary ====================
>
> Name: System-jr.948
> Author: jr
> Time: 5 May 2017, 12:08:58.857884 am
> UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
> Ancestors: System-ul.947
>
> incorporate behaviors from other environments in allBehaviorsDo:
>
> This enables senders/implementors and method searches across environments.

Wasn't the idea to have each environment its own SystemNavigation?
This change would break that.

Levente

>
> =============== Diff against System-ul.947 ===============
>
> Item was changed:
>  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
>  allBehaviorsDo: aBlock
>       "Evaluate the argument, aBlock, for each kind of Behavior in the system
>       (that is, Object and its subclasses and Traits).
>       ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
>       behaviors for which the following should be executed:
>
>               Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].
>
>       but what follows is way faster than enumerating all objects."
>
> +     Environment allInstancesDo: [:environment |
> +             environment allClassesAndTraitsDo: [ :class |
> +                     aBlock value: class.
> +                     class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
> +                             aBlock value: class class ] ] ]!
> -     self environment allClassesAndTraitsDo: [ :class |
> -             aBlock value: class.
> -             class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
> -                     aBlock value: class class ] ]!



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Eliot Miranda-2
In reply to this post by Jakob Reschke


On Tue, May 16, 2017 at 3:09 PM, Jakob Reschke <[hidden email]> wrote:
Hi,

I almost expected this feedback regarding allInstances ;-) If the change is still only in the Inbox, no harm should have been done, otherwise somebody else should revert it in trunk.

OK, good :-)
 
An alternative would be to enumerate only the Environments registered in that class pool variable. It requires everyone to use the correct "constructor" though, when the Environment is set up.

Surely an Environment is installed in some other environment, much like a class being installed in its superclass, and hence being present in its superclass's subclasses array.  Hence one can enumerate all classes starting from the thisClass's of the subclasses of Class class (see Class class>>rootsOfTheWorld).

BTW, rootsOfTheWorld is currently defined as


For the sake of learning some more: I have plenty of garbage environments in my image (due to test cases creating them and references I will have to track down at another time), but the allInstancesDo does not remarkably slow down the navigation features for me. Which cases do you have in mind when you say that it does not scale?

Multi-gigabyte 64-bit images.
 

Best,
Jakob

Am 16.05.2017 23:21 schrieb "Eliot Miranda" <[hidden email]>:
Hi Jakob,



On Tue, May 16, 2017 at 10:09 AM, <[hidden email]> wrote:
A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-jr.948.mcz

==================== Summary ====================

Name: System-jr.948
Author: jr
Time: 5 May 2017, 12:08:58.857884 am
UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
Ancestors: System-ul.947

incorporate behaviors from other environments in allBehaviorsDo:

This enables senders/implementors and method searches across environments.

=============== Diff against System-ul.947 ===============

Item was changed:
  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
  allBehaviorsDo: aBlock
        "Evaluate the argument, aBlock, for each kind of Behavior in the system
        (that is, Object and its subclasses and Traits).
        ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
        behaviors for which the following should be executed:

                Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].

        but what follows is way faster than enumerating all objects."

+       Environment allInstancesDo: [:environment |
+               environment allClassesAndTraitsDo: [ :class |
+                       aBlock value: class.
+                       class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
+                               aBlock value: class class ] ] ]!
-       self environment allClassesAndTraitsDo: [ :class |
-               aBlock value: class.
-               class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
-                       aBlock value: class class ] ]!

Forgive me for being blunt but Environment allInstancesDo: is absurd and unacceptable.  Environments *must* build some kind of graph that can be enumerated without recourse to a hammer like allInstancesDo:.  This simply doesn't scale.  And it suffers the problem of enumerating environments that are no longer in use but have yet to be garbage collected.  Please roll back this change and take a better approach.

_,,,^..^,,,_
best, Eliot






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Eliot Miranda-2
In reply to this post by Jakob Reschke
Hi Jakob,

   (ignore the earlier reply)

On Tue, May 16, 2017 at 3:09 PM, Jakob Reschke <[hidden email]> wrote:
Hi,

I almost expected this feedback regarding allInstances ;-) If the change is still only in the Inbox, no harm should have been done, otherwise somebody else should revert it in trunk.

OK, good :-)
 
An alternative would be to enumerate only the Environments registered in that class pool variable. It requires everyone to use the correct "constructor" though, when the Environment is set up.


Surely an Environment is installed in some other environment, much like a class being installed in its superclass, and hence being present in its superclass's subclasses array.  Hence one can enumerate all classes starting from the thisClass's of the subclasses of Class class (see Class class>>rootsOfTheWorld).

BTW, rootsOfTheWorld is currently defined as

Class class>>rootsOfTheWorld
"return a collection of classes which have a nil superclass"
^(Smalltalk globals select: [:each | each isBehavior and: [each superclass isNil]]) asOrderedCollection

Far faster and more elegant is

Class class>>rootsOfTheWorld
"return a collection of classes which have a nil superclass"
Class subclasses
select: [:c| c theNonMetaClass superclass isNil]
thenCollect: [:mc| mc theNonMetaClass]

So if an Environment is always in relation to the root environment, and environments refer to those that they contain, all installed environments can be enumerated from the root, touching a small fraction of the entire object graph, unlike allInstancesDo: which visits every object in the heap.

For example, in a 250 Mb image


{[ProtoObject withAllSubclasses] timeToRun. [| insts | (insts := Metaclass allInstances), (insts collect: [:ea| ea theNonMetaClass])] timeToRun } #(5 15)

For the sake of learning some more: I have plenty of garbage environments in my image (due to test cases creating them and references I will have to track down at another time), but the allInstancesDo does not remarkably slow down the navigation features for me. Which cases do you have in mind when you say that it does not scale?

Multi-gigabyte images on 64-bits.  We could conceivably have images in the 10's of gigabytes soon and allInstances would crawl.  As the above illustrates, enumerating about 250Mb of objects costs about 10ms, for 40ms/Gb (and that's on quite a fast machine; the ARM is significantly slower).

Best,
Jakob

Am 16.05.2017 23:21 schrieb "Eliot Miranda" <[hidden email]>:
Hi Jakob,



On Tue, May 16, 2017 at 10:09 AM, <[hidden email]> wrote:
A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-jr.948.mcz

==================== Summary ====================

Name: System-jr.948
Author: jr
Time: 5 May 2017, 12:08:58.857884 am
UUID: 4a19b143-6a23-b549-ab15-0d548da859f4
Ancestors: System-ul.947

incorporate behaviors from other environments in allBehaviorsDo:

This enables senders/implementors and method searches across environments.

=============== Diff against System-ul.947 ===============

Item was changed:
  ----- Method: SystemNavigation>>allBehaviorsDo: (in category 'query') -----
  allBehaviorsDo: aBlock
        "Evaluate the argument, aBlock, for each kind of Behavior in the system
        (that is, Object and its subclasses and Traits).
        ar 7/15/1999: The code below will not enumerate any obsolete or anonymous
        behaviors for which the following should be executed:

                Smalltalk allObjectsDo:[:obj| obj isBehavior ifTrue:[aBlock value: obj]].

        but what follows is way faster than enumerating all objects."

+       Environment allInstancesDo: [:environment |
+               environment allClassesAndTraitsDo: [ :class |
+                       aBlock value: class.
+                       class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
+                               aBlock value: class class ] ] ]!
-       self environment allClassesAndTraitsDo: [ :class |
-               aBlock value: class.
-               class isTrait ifFalse: [ "class of a Trait is Trait, there are no MetaTraits"
-                       aBlock value: class class ] ]!

Forgive me for being blunt but Environment allInstancesDo: is absurd and unacceptable.  Environments *must* build some kind of graph that can be enumerated without recourse to a hammer like allInstancesDo:.  This simply doesn't scale.  And it suffers the problem of enumerating environments that are no longer in use but have yet to be garbage collected.  Please roll back this change and take a better approach.

_,,,^..^,,,_
best, Eliot






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Jakob Reschke
In reply to this post by Jakob Reschke
2017-05-17 1:23 GMT+02:00 Eliot Miranda <[hidden email]>:
>
> Surely an Environment is installed in some other environment, much like a
> class being installed in its superclass, and hence being present in its
> superclass's subclasses array.

A fresh Environment is completely isolated. It has no connection to
the original Smalltalk globals environment (except via its own class,
or when you put a class in it manually you may navigate to another
environment via the superclass, but Environment does not know about
that). It only gets connected with other environments when you import
something in either direction.

Accessing the upstream and downstream connected environments of a
given Environment would currently involve poking around the
'observers' and 'policies' instance variables. No useful accessors for
navigation yet, because these connections are designed to propagate
the updates of bindings, not to navigate the system.

> So if an Environment is always in relation to the root environment, and
> environments refer to those that they contain, all installed environments
> can be enumerated from the root, touching a small fraction of the entire
> object graph, unlike allInstancesDo: which visits every object in the heap.

There is no explicit hierarchy, but one could start from Smalltalk
globals (or everything in the Instances class variable) and search the
graph of observers (approximately: importers). However, this might not
find strictly *all* implementors and senders in the object memory,
contrary to what the message names #allImplementorsOf: and friends
suggest, or what might be expected from the search box.

Comments? Better ideas? I would not like to implement this if there
are serious objections to the approach from the beginning.

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Nicolas Cellier


2017-05-18 22:43 GMT+02:00 Jakob Reschke <[hidden email]>:
2017-05-17 1:23 GMT+02:00 Eliot Miranda <[hidden email]>:
>
> Surely an Environment is installed in some other environment, much like a
> class being installed in its superclass, and hence being present in its
> superclass's subclasses array.

A fresh Environment is completely isolated. It has no connection to
the original Smalltalk globals environment (except via its own class,
or when you put a class in it manually you may navigate to another
environment via the superclass, but Environment does not know about
that). It only gets connected with other environments when you import
something in either direction.

Accessing the upstream and downstream connected environments of a
given Environment would currently involve poking around the
'observers' and 'policies' instance variables. No useful accessors for
navigation yet, because these connections are designed to propagate
the updates of bindings, not to navigate the system.

> So if an Environment is always in relation to the root environment, and
> environments refer to those that they contain, all installed environments
> can be enumerated from the root, touching a small fraction of the entire
> object graph, unlike allInstancesDo: which visits every object in the heap.

There is no explicit hierarchy, but one could start from Smalltalk
globals (or everything in the Instances class variable) and search the
graph of observers (approximately: importers). However, this might not
find strictly *all* implementors and senders in the object memory,
contrary to what the message names #allImplementorsOf: and friends
suggest, or what might be expected from the search box.

Comments? Better ideas? I would not like to implement this if there
are serious objections to the approach from the beginning.


Since all classes have 1 defining environment, maybe walking the whole class hierarchy will enable collecting environments.
The chicken and egg problem is how we would find the root classes (those with nil superclass)?
...by scanning all the classes of an environment... For now we do not have so many roots, but who knows...

Of course, there could be environment that define no classes but just alias and over "globals" (static variables), but if the goal is to scan all classes, we don't care of those.



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

David T. Lewis
On Thu, May 18, 2017 at 10:57:37PM +0200, Nicolas Cellier wrote:

> 2017-05-18 22:43 GMT+02:00 Jakob Reschke <[hidden email]>:
>
> > 2017-05-17 1:23 GMT+02:00 Eliot Miranda <[hidden email]>:
> > >
> > > Surely an Environment is installed in some other environment, much like a
> > > class being installed in its superclass, and hence being present in its
> > > superclass's subclasses array.
> >
> > A fresh Environment is completely isolated. It has no connection to
> > the original Smalltalk globals environment (except via its own class,
> > or when you put a class in it manually you may navigate to another
> > environment via the superclass, but Environment does not know about
> > that). It only gets connected with other environments when you import
> > something in either direction.
> >
> > Accessing the upstream and downstream connected environments of a
> > given Environment would currently involve poking around the
> > 'observers' and 'policies' instance variables. No useful accessors for
> > navigation yet, because these connections are designed to propagate
> > the updates of bindings, not to navigate the system.
> >
> > > So if an Environment is always in relation to the root environment, and
> > > environments refer to those that they contain, all installed environments
> > > can be enumerated from the root, touching a small fraction of the entire
> > > object graph, unlike allInstancesDo: which visits every object in the
> > heap.
> >
> > There is no explicit hierarchy, but one could start from Smalltalk
> > globals (or everything in the Instances class variable) and search the
> > graph of observers (approximately: importers). However, this might not
> > find strictly *all* implementors and senders in the object memory,
> > contrary to what the message names #allImplementorsOf: and friends
> > suggest, or what might be expected from the search box.
> >
> > Comments? Better ideas? I would not like to implement this if there
> > are serious objections to the approach from the beginning.
> >
> >
> Since all classes have 1 defining environment, maybe walking the whole
> class hierarchy will enable collecting environments.
> The chicken and egg problem is how we would find the root classes (those
> with nil superclass)?
> ...by scanning all the classes of an environment... For now we do not have
> so many roots, but who knows...
>
> Of course, there could be environment that define no classes but just alias
> and over "globals" (static variables), but if the goal is to scan all
> classes, we don't care of those.

Using #allInstancesDo: is not ugly, it is just inefficient. That means we
can safely optimize it later when the need arises.

Whenever someone actually has a multi-gigabyte image that actually uses
Environments in some meaningful way, that person will probably have a better
idea of how and why the organization should be set up. Until then there is
no real problem to be solved, and no need to restrict how the organization
of Environments within an image should work.

$0.02,

Dave


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

Levente Uzonyi
On Thu, 18 May 2017, David T. Lewis wrote:

> On Thu, May 18, 2017 at 10:57:37PM +0200, Nicolas Cellier wrote:
>> 2017-05-18 22:43 GMT+02:00 Jakob Reschke <[hidden email]>:
>>
>> > 2017-05-17 1:23 GMT+02:00 Eliot Miranda <[hidden email]>:
>> > >
>> > > Surely an Environment is installed in some other environment, much like a
>> > > class being installed in its superclass, and hence being present in its
>> > > superclass's subclasses array.
>> >
>> > A fresh Environment is completely isolated. It has no connection to
>> > the original Smalltalk globals environment (except via its own class,
>> > or when you put a class in it manually you may navigate to another
>> > environment via the superclass, but Environment does not know about
>> > that). It only gets connected with other environments when you import
>> > something in either direction.
>> >
>> > Accessing the upstream and downstream connected environments of a
>> > given Environment would currently involve poking around the
>> > 'observers' and 'policies' instance variables. No useful accessors for
>> > navigation yet, because these connections are designed to propagate
>> > the updates of bindings, not to navigate the system.
>> >
>> > > So if an Environment is always in relation to the root environment, and
>> > > environments refer to those that they contain, all installed environments
>> > > can be enumerated from the root, touching a small fraction of the entire
>> > > object graph, unlike allInstancesDo: which visits every object in the
>> > heap.
>> >
>> > There is no explicit hierarchy, but one could start from Smalltalk
>> > globals (or everything in the Instances class variable) and search the
>> > graph of observers (approximately: importers). However, this might not
>> > find strictly *all* implementors and senders in the object memory,
>> > contrary to what the message names #allImplementorsOf: and friends
>> > suggest, or what might be expected from the search box.
>> >
>> > Comments? Better ideas? I would not like to implement this if there
>> > are serious objections to the approach from the beginning.
>> >
>> >
>> Since all classes have 1 defining environment, maybe walking the whole
>> class hierarchy will enable collecting environments.
>> The chicken and egg problem is how we would find the root classes (those
>> with nil superclass)?
>> ...by scanning all the classes of an environment... For now we do not have
>> so many roots, but who knows...
>>
>> Of course, there could be environment that define no classes but just alias
>> and over "globals" (static variables), but if the goal is to scan all
>> classes, we don't care of those.
>
> Using #allInstancesDo: is not ugly, it is just inefficient. That means we
> can safely optimize it later when the need arises.
>
> Whenever someone actually has a multi-gigabyte image that actually uses
> Environments in some meaningful way, that person will probably have a better

You don't have to use Environments to be affected by the change. It's
enough if you use SystemNavigation (senders, implementors, etc).

Levente

> idea of how and why the organization should be set up. Until then there is
> no real problem to be solved, and no need to restrict how the organization
> of Environments within an image should work.
>
> $0.02,
>
> Dave

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-jr.948.mcz

David T. Lewis
On Fri, May 19, 2017 at 01:46:09AM +0200, Levente Uzonyi wrote:

> On Thu, 18 May 2017, David T. Lewis wrote:
>
> >On Thu, May 18, 2017 at 10:57:37PM +0200, Nicolas Cellier wrote:
> >>2017-05-18 22:43 GMT+02:00 Jakob Reschke <[hidden email]>:
> >>
> >>> 2017-05-17 1:23 GMT+02:00 Eliot Miranda <[hidden email]>:
> >>> >
> >>> > Surely an Environment is installed in some other environment, much
> >>like a
> >>> > class being installed in its superclass, and hence being present in
> >>its
> >>> > superclass's subclasses array.
> >>>
> >>> A fresh Environment is completely isolated. It has no connection to
> >>> the original Smalltalk globals environment (except via its own class,
> >>> or when you put a class in it manually you may navigate to another
> >>> environment via the superclass, but Environment does not know about
> >>> that). It only gets connected with other environments when you import
> >>> something in either direction.
> >>>
> >>> Accessing the upstream and downstream connected environments of a
> >>> given Environment would currently involve poking around the
> >>> 'observers' and 'policies' instance variables. No useful accessors for
> >>> navigation yet, because these connections are designed to propagate
> >>> the updates of bindings, not to navigate the system.
> >>>
> >>> > So if an Environment is always in relation to the root environment,
> >>and
> >>> > environments refer to those that they contain, all installed
> >>environments
> >>> > can be enumerated from the root, touching a small fraction of the
> >>entire
> >>> > object graph, unlike allInstancesDo: which visits every object in the
> >>> heap.
> >>>
> >>> There is no explicit hierarchy, but one could start from Smalltalk
> >>> globals (or everything in the Instances class variable) and search the
> >>> graph of observers (approximately: importers). However, this might not
> >>> find strictly *all* implementors and senders in the object memory,
> >>> contrary to what the message names #allImplementorsOf: and friends
> >>> suggest, or what might be expected from the search box.
> >>>
> >>> Comments? Better ideas? I would not like to implement this if there
> >>> are serious objections to the approach from the beginning.
> >>>
> >>>
> >>Since all classes have 1 defining environment, maybe walking the whole
> >>class hierarchy will enable collecting environments.
> >>The chicken and egg problem is how we would find the root classes (those
> >>with nil superclass)?
> >>...by scanning all the classes of an environment... For now we do not have
> >>so many roots, but who knows...
> >>
> >>Of course, there could be environment that define no classes but just
> >>alias
> >>and over "globals" (static variables), but if the goal is to scan all
> >>classes, we don't care of those.
> >
> >Using #allInstancesDo: is not ugly, it is just inefficient. That means we
> >can safely optimize it later when the need arises.
> >
> >Whenever someone actually has a multi-gigabyte image that actually uses
> >Environments in some meaningful way, that person will probably have a
> >better
>
> You don't have to use Environments to be affected by the change. It's
> enough if you use SystemNavigation (senders, implementors, etc).
>

Ah, ok. I did not understand that.

Dave

> Levente
>
> >idea of how and why the organization should be set up. Until then there is
> >no real problem to be solved, and no need to restrict how the organization
> >of Environments within an image should work.
> >
> >$0.02,
> >
> >Dave
>