I don't remember reciving any trafick from this list....
I was reminded of the list by Brian Rice in IRC...
When looking at this URL: http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000027.ht...
I was struck by the fact that this is ALMOST EXACTLY MY IDEA!!!! =P
See paper at: http://users.rcn.com/alangrimes/UCE/sphere.txt
Which is 2 years older....
SO WHERE THE HECK HAVE YOU PPL BEEN HIDING DURING THE 2 YEARS BETWEEN WHEN I PUBLISHED MY ARTICLE AND THIS E-MAIL POSTING? =P
Anyway, lets get to work now...
I reciently discovered Environment, what a brilliant class....
Prior to this discovery I wrote base and interface classes for my Sphere design... however I am extremely impressed by many of the design features of Environment.
I was feebly trying to hack togeather a system that would allow me to visualize the graphical structure of the system........... =\
I later abandoned the graph concept for the sake of expediancy and have been futzing with the base security model, isolating the subtrees ( in the terminology of the e-mail reffered to above)... The only problem with this is that there are times when you WANT to violate the heirarchy of the system by putting a refferance to the root (or a peer) environment in some nested environment. This is necessary to support a "root shell" type thingy....
All these problems will be VERY whackable if everyone on this list will just spill what they know and start solving this stuff.
At 10:21 PM 1/29/2004 Thursday, Alan Grimes wrote:
I don't remember reciving any trafick from this list....
I was reminded of the list by Brian Rice in IRC...
When looking at this URL: http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000027.ht...
I was struck by the fact that this is ALMOST EXACTLY MY IDEA!!!! =P
See paper at: http://users.rcn.com/alangrimes/UCE/sphere.txt
Which is 2 years older....
Thanks -- I'm always happy to learn of earlier work that's along the same lines. At http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000028.ht...
I write my own credit self-correction to my earlier message as follows:
Oops, I forgot to mention the biggest credit-where-due on this: Udi Shapiro and the use of nested virtual meta-reflective interpreters in a network in Flat Concurrent Prolog. He did indeed reify eval and absorb apply (#4) and he did indeed use source-to-source transformation to simulate meta-interpretation cheaply (#10).
As I read over my description, I think it's all there in Udi's work (except for #9, which is obvious anyway). My message is only new imagery for explaining an old idea. I'm embarrassed. Well, at least the idea I almost stole is a good one. ;)
The work I refer to here is actually Safra, M. and Shapiro, E. Y., Meta Interpreters for Real, In Information Processing 86, Kugler, H.-J. (ed.), North-Holland, Amsterdam, pp. 271--278, 1986. http://citeseer.nj.nec.com/context/72525/0 http://portal.acm.org/citation.cfm?id=58180&dl=ACM&coll=portal
Since I don't yet know Sphere, I can't yet comment on whether or not this paper represents almost the same idea 15 years yet earlier.
---------------------------------------- Text by me above is hereby placed in the public domain
Cheers, --MarkM
Thanks -- I'm always happy to learn of earlier work that's along the same lines. At http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000028.ht...
My appologies, I discovered that message some minutes after sending my over-eager message... Indeed, my own text refers to another which must be 23 years old now and a concept of a "System Oriented Operating System"
I write my own credit self-correction to my earlier message as follows:
Oops, I forgot to mention the biggest credit-where-due on this: Udi Shapiro and the use of nested virtual meta-reflective interpreters in a network in Flat Concurrent Prolog. He did indeed reify eval and absorb apply (#4) and he did indeed use source-to-source transformation to simulate meta-interpretation cheaply (#10).
As I read over my description, I think it's all there in Udi's work (except for #9, which is obvious anyway). My message is only new imagery for explaining an old idea. I'm embarrassed. Well, at least the idea I almost stole is a good one. ;)
At 10:54 PM 1/29/2004 Thursday, Alan Grimes wrote:
My appologies, I discovered that message some minutes after sending my over-eager message...
No problem. As your first message emphasizes, the important thing is to get on with it. I agree.
Indeed, my own text refers to another which must be 23 years old now and a concept of a "System Oriented Operating System"
I'd love to know more about this. Do you have a pointer/citation of some sort?
---------------------------------------- Text by me above is hereby placed in the public domain
Cheers, --MarkM
Indeed, my own text refers to another which must be 23
years old now and a concept of a "System Oriented Operating System"
I'd love to know more about this. Do you have a pointer/citation of some sort?
It was a musty old tome at my community college that had a page or two about it....
Mark S. Miller wrote:
No problem. As your first message emphasizes, the important thing is to get on with it. I agree.
Okay, here's part of my feble attempt at starting an implementation of Sphere... The two other categories are Sphere-Core and Sphere-devel... The other two reflect my attempts at trying to design a squeak implementation.
The Interface and Outerface are the most important classes because they reflect a sphere's API and the published interface to a sphere respectively....
The other comment I have is about where and when to introduce distributed concepts into the OS.
My own philosophy is to design the abstractions to most accurately reflect the fundamental nature of the machine. As "networked computers" are a sub-set of "computers" I designed Sphere to run on Computers _THEN_ designed a Distributed processing sphere which provides, internally, any customized distributed processing API without poluting the underlying system.
Object subclass: #Sphere instanceVariableNames: 'Name interfaces Outerfaces Memory Supervisor Subordinants tasks visitingTasks MyPriority allowRecursiveCalls ' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !Sphere commentStamp: 'ATG 10/16/2003 17:00' prior: 0! This is the base class for a system oriented operating system called "sphere".
For reasons of system durability, this class is to be used to manage the actual spheres and not directly linked to any Sphere software. This is neccessary to enhance compatibility across versions and through time. !
!Sphere methodsFor: 'accessing' stamp: 'ATG 10/17/2003 16:29'! changeNameTo: aNewName
"om."
Name _ aNewName. ! !
!Sphere methodsFor: 'accessing' stamp: 'ATG 10/19/2003 17:33'! interface: newInterface interfaces _ newInterface. ! !
!Sphere methodsFor: 'accessing' stamp: 'ATG 10/17/2003 16:51'! name ^Name.! !
!Sphere methodsFor: 'accessing' stamp: 'ATG 10/19/2003 17:35'! outerface: newOuterface Outerfaces _ newOuterface. ! !
!Sphere methodsFor: 'error handling' stamp: 'AFG 10/4/2002 14:14'! serverFailure "should a server this sphere depend on fail..." self die. ! !
!Sphere methodsFor: 'initialization' stamp: 'ATG 12/18/2003 19:02'! initialize super initialize. Name _ 'UNUSED'.
" a generic sphere doesn't need an interface... " " interfaces _ SphereInterfaceBase new. Outerfaces _ SphereOuterfaceBase new. " Memory _ BogusMemory new. Subordinants _ Array new. tasks _ Heap new. visitingTasks _ Collection new. allowRecursiveCalls _ true.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:01'! addSubordinant: aSubordinantSphere
Subordinants add: aSubordinantSphere.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:48'! assignMemory: aVirtualMemoryProvider
Memory _ aVirtualMemoryProvider.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 21:56'! doToAllChildren: aBlock
Subordinants do: aBlock.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:03'! extTryService: aMessage! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:04'! intTryService: aMessage! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 21:27'! memorySize
^ Memory size.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:46'! parent
^ Supervisor.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:47'! parent: aNewSupervisor
Supervisor _ aNewSupervisor.! !
!Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:27'! removeSubordinant: aDerilictSubordinant ! !
"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
Sphere class instanceVariableNames: ''!
!Sphere class methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 22:13'! createNewIn: aParentSphere
| aNewSphere | aNewSphere _ self new. aNewSphere parent: aParentSphere. ^ aNewSphere. ! !
!Sphere class methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:50'! createNewIn: aParentSphere with: aMemory
| aNewSphere | aNewSphere _ self new. aNewSphere parent: aParentSphere; assignMemory: aMemory. ^ aNewSphere. ! !
Object subclass: #SphereCallInterface instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereCallInterface commentStamp: 'ATG 10/17/2003 17:28' prior: 0! The syscall interface for Sphere. !
"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
SphereCallInterface class instanceVariableNames: ''!
!SphereCallInterface class methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:58'! SystemCall: aMessage
"Tries to find a sphere within or available to the current context which understands this message. This is a secure synchronous call from the sender's perspective. from the receiver's perspective it is an assynchronous event which executes one of the public interfaces." ! !
Object subclass: #SphereInterfaceBase instanceVariableNames: 'owner ' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereInterfaceBase commentStamp: 'ATG 10/16/2003 17:32' prior: 0! Base class for interface objects.
Each Sphere is likley to have two children of this class, one exclusively for subspheres and one that is accessable publicly.!
!SphereInterfaceBase methodsFor: 'thread navigation' stamp: 'ATG 10/17/2003 00:24'! enter: aSphere
"switch the current thread's context to the new one." ! !
!SphereInterfaceBase methodsFor: 'thread navigation' stamp: 'ATG 10/17/2003 01:03'! home
"return to home context"! !
!SphereInterfaceBase methodsFor: 'thread navigation' stamp: 'ATG 10/17/2003 01:03'! leave
"leave current context" ! !
!SphereInterfaceBase methodsFor: 'security' stamp: 'ATG 10/17/2003 01:10'! giveAccess
"Grant the thread's home access to this sphere." ! !
!SphereInterfaceBase methodsFor: 'security' stamp: 'ATG 10/17/2003 01:10'! requestAuthent: key
"request security access to the parent context with provided key." ! !
!SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 10/17/2003 21:11'! HELP "!!!!!!!!"
"return a help message for this context."
^ 'Welcome to the Sphere Operating System. This is an early prototype which is intended to demonstrate its basic concepts and perhaps even serve as the basis for a more capable version. You are in a context called a Sphere. The system calls available here are derived from the services provided by other Spheres which are also within this context as well as (possibly) spheres outside of this current context. Use the List function to learn what spheres may be here to explore. use menu function to learn what commands you can try.'! !
!SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 12/18/2003 19:03'! VMLook
"return a virtual memory report for this and all subordinant contexts."
^ owner memorySize.! !
!SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 12/18/2003 19:03'! getCurrentContextName
"returns the name of the current context."
^ owner name. ! !
!SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 10/17/2003 22:07'! list
"returns a list of spheres within this context."
| tempString |
tempString _ String new.
Owner doToAllChildren: [: x | tempString append: (x name). tempString append: ' ' ].
^ tempString.! !
!SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 10/17/2003 00:23'! menu
"I think this should return a list of methods of the interface class and all the commands available within the current context, including interfaces provided to parent contexts for both program and user interfaces." ! !
!SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 14:05'! disconnect
"disconnect a client gracefully." ! !
!SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 14:06'! disconnect: serverSphere
"disconnect a client or server ungracefully." ! !
!SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 00:22'! graph
"Returns a dependancy graph that may be converted into any of a number of types of user reports." ! !
!SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 01:04'! recogClient
"Recognise the home of the thread as a client." ! !
!SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 12/18/2003 19:04'! create "Create a gnu sphere within the current context."
| newSphere |
newSphere _ Sphere createNewIn: owner.
owner addSubordinant: newSphere.
^ newSphere. ! !
!SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 00:02'! interpret: someSpherewarez in: thisSphere
! !
!SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 22:21'! murder: theVictim
"not much needs to be done for process cleanup in a GC'd environment... This will delink the sphere and run a GC..." ! !
!SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 12/18/2003 19:04'! setHomeSphere: newOwner
owner _ newOwner. ! !
!SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 22:22'! shutdown: aSphere
"Attempt to run a Sphere's cleanup routines and shutdown gracefully." ! !
!SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 01:07'! transfer
"give this sphere's responsibilities to the caller, used for On-the-mosquito upgrading." ! !
!SphereInterfaceBase methodsFor: 'interface managment' stamp: 'ATG 12/18/2003 19:04'! installInterface: newInterface owner interface: newInterface.! !
!SphereInterfaceBase methodsFor: 'interface managment' stamp: 'ATG 12/18/2003 19:04'! installOuterface: newOuterface owner outerface: newOuterface.! !
"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
SphereInterfaceBase class instanceVariableNames: ''!
!SphereInterfaceBase class methodsFor: 'as yet unclassified' stamp: 'ATG 10/18/2003 11:25'! new: homeSphere
"set up the interface to work with the provided sphere."
^ self new; setHomeSphere: homeSphere. ! !
Object subclass: #SphereOuterfaceBase instanceVariableNames: 'owner ' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'!
Object subclass: #SphereSoftware instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereSoftware commentStamp: 'ATG 10/16/2003 16:57' prior: 0! Abstract class for all software written for Sphere including drivers and user software.!
I'm actually making some small progress with my design. The next step seems to be to implement and test the following algorithm:
"Sphere Call Interface"
- Each "Sphere" has its own call interface. which is provided to ins own internal environment without regards to the language actually used to code that environment. It is therefore a given that the physical _CODE_ calling the call interface is from the same sphere as the instance of Sphere Call Interface.
1. Since threads can migrate across contexts and "visit" nested spheres, it is therefore necessary to determine, in an unforgable manner, the current context of the thread.
2. Look at the name of the target system call, the parameter provided to the call interface.
3. Attempt to find an implementation of the system call in The current context's call _interface_.
If this succedes go to 7.
4. Attempt to find the message in the _outerface_ of any of the spheres nested within the current context.
if this succedes go to 6.
5. go to step 3.
6. add the current task to the "visiting tasks" of the owner of the outerface which is servicing the system call.
7. Execute the target code within the context that was determined in #1.
8. Handle the return call, cleaning up the "visiting tasks" structure if necessary.
Contingiency: if a sphere dies, send an exception to all visiting tasks and return them to their calling context.
Any suggestions? =\
squeak-e@lists.squeakfoundation.org