I am trying to load the Smalltalk emulator into Self 4.1.2 (I said I would get around to this one day ;-) but it needs Mango in order to generate the parser.
The version I have is from 1992 and it include slot privacy declarations (which Self 4 doesn't understand) and an incompatible name space structure. Both problems are to work around, but first I thought I would ask if there are any newer versions available that fix these problems.
BTW, I notived that Self 4.1.2 has replaced 'unixFile' with 'unixGlobals os_file'. Any reason for that?
-- Jecel
Jecel Assumpcao Jr wrote:
I am trying to load the Smalltalk emulator into Self 4.1.2 (I said I would get around to this one day ;-) but it needs Mango in order to generate the parser.
The version I have is from 1992 and it include slot privacy declarations (which Self 4 doesn't understand) and an incompatible name space structure. Both problems are to work around, but first I thought I would ask if there are any newer versions available that fix these problems.
BTW, I notived that Self 4.1.2 has replaced 'unixFile' with 'unixGlobals os_file'. Any reason for that?
-- Jecel
Missing old school friends? Find them here: http://click.egroups.com/1/4055/0/_/8257/_/959635187/
I'm not sure, but I think the cdrom i gave to you with Smalltalk stuff have
sources for the 4.0 Self version...
Reinaldo
Reinaldo Silveira wrote:
I'm not sure, but I think the cdrom i gave to you with Smalltalk stuff have sources for the 4.0 Self version...
I just checked it on another computer (my 48x drive no longer reads that CD-R for some reason) and and you are right - I don't know how I missed it the first time.
David Ungar wrote:
We certainly have such a version. (It is more recent than what you have but will still need tweaking.) Has mango ever been part of a previous release? (It would make it easier to get permission if that were true.)
The version I have was sent to me by Ole Agesen directly via email, but Reinaldo's CD-R was just a copy of the old Self web site so I guess Mango-4_0_tar.gz was available in the contrib directory.
It really doesn't matter in any case as the Smalltalk Emulator removes Mango from the system as soon as it has finished creating the parser.
And, the reason to replace unixFile is for portability. You should use os_file, which will work on any platform.
Good idea... I'll do this patch soon. Meanwhile, by copying the sources to the applications/smalltalk and applications/mango directories, making a link to the applications/smalltalk/smalltalkSrc directory and executing the following in the "BareBones" snapshot:
globals _AddSlots: (| unixFile = os_file |). traits _AddSlots: (| dictionary = traits hashTableDictionary |). bootstrap read: 'smalltalk' From: 'applications/smalltalk'. smalltalkEmulator workspace
I got a (nearly) working Smalltalk in Self 4.1.2. For some reason, only the classes in "Collections-System", "Collections-Text" and "Kernel-Objects" have been loaded even though there were no error messages (at least no scary ones ;-).
Thanks to both of you. This will probably be easier than I had thought.
-- Jecel
Jecel wrote:
I got a (nearly) working Smalltalk in Self 4.1.2. For some reason, only the classes in "Collections-System", "Collections-Text" and "Kernel-Objects" have been loaded even though there were no error messages (at least no scary ones ;-).
False alarm: when I tried to track down what could have gone wrong a little later I tried calling up another browser and this one had all the classes. So Smalltalk works just fine in Self 4.1.2.
-- Jecel
Glad to hear it. - Dave
At 8:05 PM -0300 5/30/00, Jecel Assumpcao Jr wrote:
Jecel wrote:
I got a (nearly) working Smalltalk in Self 4.1.2. For some reason, only the classes in "Collections-System", "Collections-Text" and "Kernel-Objects" have been loaded even though there were no error messages (at least no scary ones ;-).
False alarm: when I tried to track down what could have gone wrong a little later I tried calling up another browser and this one had all the classes. So Smalltalk works just fine in Self 4.1.2.
-- Jecel
Failed tests, classes skipped, forgotten locker combinations. Remember the good 'ol days http://click.egroups.com/1/4053/0/_/8257/_/959727853/
We certainly have such a version. (It is more recent than what you have but will still need tweaking.) Has mango ever been part of a previous release? (It would make it easier to get permission if that were true.)
And, the reason to replace unixFile is for portability. You should use os_file, which will work on any platform.
- Dave
At 6:17 PM -0300 5/29/00, Jecel Assumpcao Jr wrote:
I am trying to load the Smalltalk emulator into Self 4.1.2 (I said I would get around to this one day ;-) but it needs Mango in order to generate the parser.
The version I have is from 1992 and it include slot privacy declarations (which Self 4 doesn't understand) and an incompatible name space structure. Both problems are to work around, but first I thought I would ask if there are any newer versions available that fix these problems.
BTW, I notived that Self 4.1.2 has replaced 'unixFile' with 'unixGlobals os_file'. Any reason for that?
-- Jecel
Missing old school friends? Find them here: http://click.egroups.com/1/4055/0/_/8257/_/959635187/
In the Self tutorial/slides, it mentions that the blocks are compiled with some hidden slots.
Then when an expression that references a block is "evaluated", a clone is made with a hidden slot to the context.
(3 < 4) ifTrue: [ ^nil ].
How is that done?
Dru Nelson San Mateo, California
Painfully & painstakingly;-)
- Dave
At 1:48 AM -0700 6/2/00, Dru Nelson wrote:
In the Self tutorial/slides, it mentions that the blocks are compiled with some hidden slots.
Then when an expression that references a block is "evaluated", a clone is made with a hidden slot to the context.
(3 < 4) ifTrue: [ ^nil ].
How is that done?
Dru Nelson San Mateo, California
Failed tests, classes skipped, forgotten locker combinations. Remember the good 'ol days http://click.egroups.com/1/4053/0/_/8257/_/959935686/
Dru Nelson you wrote:
In the Self tutorial/slides, it mentions that the blocks are compiled with some hidden slots.
True. This greatly offends some people who feel they are being cheated by these tricks. This led me to take a look at some outliners for methods (just choose "sprout" from the yellow menu while pointing to a method) and noticed that Self 4.1.2 doesn't include the "pseudo slots" like 4.0 does. In fact, this lastest version seems to have some real problems with outliners and methods (it can't show the reflectee slot in a method mirror outliner without getting into a loop generating errors). Speaking of 4.1.2 UI problems, enumerators now start evaluating themselves as soon as you call them up instead of when you try to open them. This means you can never uncheck the "well known only" box before doing the enumeration.
Then when an expression that references a block is "evaluated", a clone is made with a hidden slot to the context.
Variable scoping in other languages is simulated in Self using object inheritance. By making the implicit receiver be the current context and having that point to the original receiver via a self* parent slot, you can access both "local variables" and "instance variables" (and "class variables! And "globals") in a uniform way.
When you send the 'value' message to a block, if the corresponding methods acted in the normal way you would have a "self*" slot pointing to the block itself and no way to access stuff in the context in which it appeared:
( | a <- 3. b <- 4 | a < b ifTrue: [ ^ a*b ]. a+b )
This has a block object that looks like this:
( | parent* = traits block. value = ( ^ a*b ) | )
Now if this block object is sent a 'value' message and the resulting context gets a 'self*' slot pointing to itself, then it will know about 'parent*' and 'value', but nothing about 'a' and 'b', right?
So we don't add that 'self*' slot at all, but a 'lexicalParent*' slot pointing to the context which executed the "push literal: [ ^ a*b ]" bytecode. But how can we find out that information when creating the context for the 'value' method? By this time, we no longer remember this (and it would be a good idea to know this anyway since otherwise we can't execute the "non local return" bytecode, the "^").
(3 < 4) ifTrue: [ ^nil ].
How is that done?
Yet another trick - when the bytecode tells us to push a block on the stack, we create a clone of it with an extra slot to point to the currently executing context and push that instead. Note that you can't see this in the debugger - it does every thing it can to make you think that the original block was used, not its evil twin ;-)
Now when we send the 'value' message, it will go to the modified clone instead of the block, and this clone does know about the context we are interested in and so can fill in the 'lexicalParent*' slot correctly.
From now on, everything works as claimed.
Don't worry too much about understanding all this... Self doesn't really work this way at all under the hood!!
So David's answer was probably just what you needed :-)
-- Jecel
First, Thanks Jecel!
True. This greatly offends some people who feel they are being cheated by these tricks. This led me to take a look at some outliners for
Yes, I understood the hidden slots. I don't feel tricked :-)
Variable scoping in other languages is simulated in Self using object inheritance. By making the implicit receiver be the current context and having that point to the original receiver via a self* parent slot, you can access both "local variables" and "instance variables" (and "class variables! And "globals") in a uniform way.
Yes, I understood this part too. A very elegant solution.
this (and it would be a good idea to know this anyway since otherwise we can't execute the "non local return" bytecode, the "^").
Now to the heart of the question :-)
(3 < 4) ifTrue: [ ^nil ].
How is that done?
Yet another trick - when the bytecode tells us to push a block on the stack, we create a clone of it with an extra slot to point to the currently executing context and push that instead. Note that you can't see this in the debugger - it does every thing it can to make you think that the original block was used, not its evil twin ;-)
Now when we send the 'value' message, it will go to the modified clone instead of the block, and this clone does know about the context we are interested in and so can fill in the 'lexicalParent*' slot correctly.
From now on, everything works as claimed.
OK, this is the trick I was looking for. I read about this in the slides and the Self 4.0 progs' ref. However, I didn't know how the final clone was created *efficiently*. In order for this to work in a naive way, every push of a reference would have to know if the argument was a block (a significant read barrier). Or a block would be a special object type specified in the reference so the bytecode could do this.
Is that how it works?
Don't worry too much about understanding all this... Self doesn't really work this way at all under the hood!!
I'm sure the optimizer is a whole other field in itself :-)
So David's answer was probably just what you needed :-)
The last trick is the answer I needed.
Dru Nelson San Mateo, California
self-interest@lists.selflanguage.org
-
David Ungar -
Dru Nelson -
Jecel Assumpcao Jr -
Reinaldo Silveira (local from cynthia)