Are Smalltalk and SystemOrganization "global variables". If so where are the system globals and how do I list them, within a browser and say to the Transaction window from the workspace ?
Aaron
From: "Aaron Gray" angray@beeb.net
Are Smalltalk and SystemOrganization "global variables".
Yes, they are.
If so where are the system globals and how do I list them, within a browser and say to the Transaction window from the workspace ?
All the globals are in Smalltalk, which is an instance of SystemDictionary.
Evaluate the following statements with print to obtain a feeling for this:
Smalltalk class Smalltalk includesKey: #Smalltalk Smalltalk includesKey: #SystemOrganization
Smalltalk is also the Dictionary that contains all classes. That is OK, classes are globally defined entities, too.
Now, what you are really after is that:
Smalltalk reject: [:item | item class isMeta ]
Evaluate it with 'inspect' This opens an inspector that shows you all globals that are not classes. (see footnote ** below)
Here is exactly what you want: (Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
This prints the names of the non-class globals into the transcript window. Note that (Smalltalk reject: [:item | item class isMeta ]) answers selected associations from Smalltalk. With associationsDo: [:assoc | Transcript show: assoc key printString; cr].
we print only the keys of the assocs, the values of some globals have huge printed representations; it is therefore not a good idea to write them into the transcript.
**) The 'class isMeta' looks like magic, but it is not. isMeta is defined in the instance protocol of classes Behavior and MetaClass. The class of a class is an instance of MetaClass, when sent the message isMeta, it answers true. Classes answer false.
Greetings, Boris
Boris,
Thanks alot, I realize it is going to take me quite a while before I feel ofay with Squeak.
I have periods of time where nothing I type seems to work, particularly with extracting stuff from the library and trying to get modified bits of code to work.
Oh well, I will keep at it until I feel more confident. Quick tutorials via the mailing list are good and help alot.
The main problem I seem to have with looking at code is seeing what class certain methods are for example in :-
(Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
What class is key, if I look at Association I see key returns a key, but what class is that key that printString is being applied to ? I find this same problem over and over, is there a simple solution ? I may have been given the answer at somepoint but cannot remember.
Thanks,
Aaron
On Thu, 9 Dec 2004 00:11:59 -0000, Aaron Gray angray@beeb.net wrote:
The main problem I seem to have with looking at code is seeing what class certain methods are for example in :-
(Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
What class is key, if I look at Association I see key returns a key, but what class is that key that printString is being applied to ? I find this same problem over and over, is there a simple solution ? I may have been given the answer at somepoint but cannot remember.
You can put a self halt before the "Transcript show" to find out.
The main problem I seem to have with looking at code is seeing what class certain methods are for example in :-
(Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
What class is key, if I look at Association I see key returns a key, but what class is that key that printString is being applied to ? I find this same problem over and over, is there a simple solution ? I may have been given the answer at somepoint but cannot remember.
You can put a self halt before the "Transcript show" to find out.
Err, tried it, but cannot see how ?
Aaron
On Thu, 9 Dec 2004 02:50:24 -0000, Aaron Gray angray@beeb.net wrote:
The main problem I seem to have with looking at code is seeing what class certain methods are for example in :-
(Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
What class is key, if I look at Association I see key returns a key, but what class is that key that printString is being applied to ? I find this same problem over and over, is there a simple solution ? I may have been given the answer at somepoint but cannot remember.
You can put a self halt before the "Transcript show" to find out.
Err, tried it, but cannot see how ?
Click debug, then inspect assoc (or assoc key) from the debugger. Inspectors show the class of the object it is looking at in the window title bar. Explorers don't.
The main problem I seem to have with looking at code is seeing what class certain methods are for example in :-
(Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
What class is key, if I look at Association I see key returns a key, but what class is that key that printString is being applied to ? I find this same problem over and over, is there a simple solution ? I may have been given the answer at somepoint but cannot remember.
You can put a self halt before the "Transcript show" to find out.
Err, tried it, but cannot see how ?
Click debug, then inspect assoc (or assoc key) from the debugger. Inspectors show the class of the object it is looking at in the window title bar. Explorers don't.
Ah.
The key is a Symbol.
So you have to run the code to find that out. And there is no other simple way ?
Thanks, I should have known that,
Aaron
Many thanks
On Thu, 9 Dec 2004 03:29:59 -0000, Aaron Gray angray@beeb.net wrote:
The main problem I seem to have with looking at code is seeing what class certain methods are for example in :-
(Smalltalk reject: [:item | item class isMeta ]) associationsDo: [:assoc | Transcript show: assoc key printString; cr].
What class is key, if I look at Association I see key returns a key, but what class is that key that printString is being applied to ? I find this same problem over and over, is there a simple solution ? I may have been given the answer at somepoint but cannot remember.
You can put a self halt before the "Transcript show" to find out.
Err, tried it, but cannot see how ?
Click debug, then inspect assoc (or assoc key) from the debugger. Inspectors show the class of the object it is looking at in the window title bar. Explorers don't.
Ah.
The key is a Symbol.
So you have to run the code to find that out. And there is no other simple way ?
Class comments might describe this, but in this case it seems not. Actually, I've found it more convenient to actually find out information like this either through sending #class to an instance or viewing it in an inspector, ie. like you say, through code. Not sure how the others do it though.
Thanks, I should have known that,
Remember, its a great environment for exploration, running code should be fun :)
Aaron,
Ah.
The key is a Symbol.
So you have to run the code to find that out. And there is no other simple way ?
A more "retrospective" (?) way, or a way to avoid to execute critical code directly is to ask "themselves" (i.e. objects) what invariant they satisfy.
In this case, a line something like:
Smalltalk keys collect: [:i | i class].
would return a set with just one element (Symbol). This means that the keys of Smalltalk are all Symbols.
Thanks, I should have known that,
Now, David (Lewis) and my suggestion about inserting "self halt" are going to make sense?
Yes, but this is one of the downside of a highly dynamic language. The "type" info helps to understand code. Of course, the info can be supplied in other forms like comments or unit tests so doesn't necessarily have to be part of the code...
-- Yoshiki
So you have to run the code to find that out. And there is no other simple way ?
A more "retrospective" (?) way, or a way to avoid to execute critical code directly is to ask "themselves" (i.e. objects) what invariant they satisfy.
In this case, a line something like:
Smalltalk keys collect: [:i | i class].
would return a set with just one element (Symbol). This means that the keys of Smalltalk are all Symbols.
Thats nice, simple and very nice.
Now, David (Lewis) and my suggestion about inserting "self halt" are going to make sense?
Yes, on the second time round, yes.
Yes, but this is one of the downside of a highly dynamic language. The "type" info helps to understand code. Of course, the info can be supplied in other forms like comments or unit tests so doesn't necessarily have to be part of the code...
Before getting into Smalltalk, I was a stongly typed fan, but now am getting into "lazy typing". On the otherhand I would like some form of assertion mechanism that can disappear at compile time if debugging or type checking is disabled. But to implement such a mechanism properly would be quite alot of work to get right both technically and for good usage. Although a simple starting technology would be possible followed by incremental refinement and this may well allow the problem to be solved in a comprehensive manner.
I was thinking about type specs either being single types or as type domains being lists or patterns of types. Domains could be named and used as type qualifiers that could be either coded as run time checks or disolved out giving no runtime overhead.
Aaron
Hi
I suggest to think twice if you need global this means that your design is not that good. In addition that are plenty of excellent books that I collected over the year and I suggest you to browse them. You will find answer to a lot of your questions. In addition, the answers are also in the system as yoshiki mentioned. So the best way to learn is to open the box.
Have fun
Stef
Hi,
I'm looking for Squeak Benchmarks allowing for performance metrics and comparison of squeak applications.
Cheers, Houssam ____ "Le paradis touche les pieds des mères..."
"Fakih" fakih@ensm-douai.fr wrote:
Hi,
I'm looking for Squeak Benchmarks allowing for performance metrics and comparison of squeak applications.
Look on SqueakMap for the package 'Benchmarks'. If you're not already familiar with SqueakMap, look at http://minnow.cc.gatech.edu/squeak/2726
The 'Green Book Benchmarks' have been in use for about 25 years now so we have some idea of performance changes all the way back to Alto, Dorado, 286's, ARM2's and Perq's.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Never test for an error condition you don't know how to handle. - Steinbach
squeak-dev@lists.squeakfoundation.org
-
Aaron Gray -
Boris Gaertner -
Fakih -
stéphane ducasse -
Tim Rowledge -
Yar Hwee Boon -
Yoshiki Ohshima