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 ] ]! |
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? |
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 |
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 ] ]! |
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: 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 |
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]>:
|
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: |
In reply to this post by Jakob Reschke-2
On Tue, May 16, 2017 at 3:09 PM, Jakob Reschke <[hidden email]> wrote:
OK, good :-)
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
Multi-gigabyte 64-bit images.
_,,,^..^,,,_ best, Eliot |
In reply to this post by Jakob Reschke-2
Hi Jakob,
(ignore the earlier reply) On Tue, May 16, 2017 at 3:09 PM, Jakob Reschke <[hidden email]> wrote:
OK, good :-)
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)
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, Eliot |
In reply to this post by Jakob Reschke-2
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. |
2017-05-18 22:43 GMT+02:00 Jakob Reschke <[hidden email]>: 2017-05-17 1:23 GMT+02:00 Eliot Miranda <[hidden email]>: 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. |
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 |
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 |
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 > |
Free forum by Nabble | Edit this page |