Writing an Operating System in Ada
in [ADA]
|
Prev: GNAT requires body of generic unit to be present at build?
Next: ASISEyes : show you the ASIS interpretation of an Ada source
From: Georg Bauhaus on 18 Jan 2010 06:23 Dmitry A. Kazakov schrieb: > On Sat, 16 Jan 2010 13:18:46 -0800 (PST), Maciej Sobczak wrote: > >> On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> >> wrote: >> >>>> The blob becomes useful only when it is loaded into memory. >>> How does it? >> By becoming a typed entity that is referenced within the actively >> executed program. This is the moment when blob becomes useful. > > So the file containing a movie is useless? > >> Several posts ago you have requested to execute actions on objects. >> "Play" was an action on the movie - you wanted that. When I said that >> the blob (a file, essentially) becomes useful when it is loaded into >> memory, I meant that it is the interpretation of the blob that gives >> it some requested capabilities. > > Is there any player that loads movies into the memory? This topic is rather interesting considering languages' I/O sections. So its dicussion will profit from keeping it technical. (The obvious idea here is that naggy remarks about some presumed meaning of "load" could be more lucid.) If there is a misunderstanding, please help: in a world of existing separate OSs, or of to be designed OSs, would their respective persistence layers allow, given the identifier of some object, (1) calling primitive subs defined with the object's type T (2) learning about T's subs in case the object was stored by some program (defining T) not known to the caller, (3) adding subs to T to accomodate specified processing needs of another, later program? How?
From: Dmitry A. Kazakov on 18 Jan 2010 08:50 On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote: > If there is a misunderstanding, please help: > in a world of existing separate OSs, or of to be > designed OSs, would their respective persistence layers allow, > given the identifier of some object, Identifier of some object = the object itself, like when you write in Ada: X : Integer; X is the object and an identifier of. > (1) calling primitive subs defined with the object's type T Certainly. > (2) learning about T's subs in case the object was stored > by some program (defining T) not known to the caller, No, you don't have the object then (object = identity + type + value). First you have to convert the type of the object and get a view or else another transient object of the desired type. Ada's equivalent: X : T'Class; begin ... S (X) ... -- S is a member of T'Class You might also be able to check if X in S'Class etc. > (3) adding subs to T to accomodate specified processing needs > of another, later program? How? By conversion of the object to another type: X : Integer; Y : Float := Float (X); -- Now we have sin, cos etc This conversion might happen to be a view conversion or not. 1,2,3 represent no problem. IMO the real challenge (apart from consistent implementations of MI and MD) are dynamic types marshaled between the parts of a distributed system. I didn't think much about that, so don't expect me to answer how that should be solved. Probably others might have some insights... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 18 Jan 2010 10:21 Dmitry A. Kazakov schrieb: > On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote: > >> If there is a misunderstanding, please help: >> in a world of existing separate OSs, or of to be >> designed OSs, would their respective persistence layers allow, >> given the identifier of some object, > > Identifier of some object = the object itself, like when you write in Ada: > > X : Integer; > > X is the object and an identifier of. > >> (1) calling primitive subs defined with the object's type T > > Certainly. > >> (2) learning about T's subs in case the object was stored >> by some program (defining T) not known to the caller, > > No, you don't have the object then (object = identity + type + value). > First you have to convert the type of the object and get a view or else > another transient object of the desired type. Ada's equivalent: > > X : T'Class; > begin > ... S (X) ... -- S is a member of T'Class > > You might also be able to check if X in S'Class etc. > >> (3) adding subs to T to accomodate specified processing needs >> of another, later program? How? > > By conversion of the object to another type: > > X : Integer; > Y : Float := Float (X); -- Now we have sin, cos etc This conversion of a (then) persistent Integer object to a Float object is possible because either type is known (and can be named). The meaning of conversion from Integer to Float is language defined, too. That is, either object's type is known in the program storing X as an Integer and in the program processing X as a Float, respectively. In particular, the second program "knows" about the possibility of conversion of known type Integer to known type Float. What a persistent O-O storage would have to offer is something in addition. In Toulouse: X : Private_Type_A; begin OO_Store.Put(X); end; Then, where Identity is an identifier, or the object, or a handle, or a filename, or ...: Pass(Identity(X), From => Toulouse, To => Hamburg); In Hamburg: Y : Private_Type_B; begin OO_Store.Get(Y [, <from the identity>]); How is Hamburg enabled to learn what Toulouse.Private_Type_A is with the persistence layer functioning as the only source of information about the object? Which operations does it support? What kind of conversions are possible, what granularity of access to the object's innards might be needed to reify the interface of Hamburg.Private_Type_B? I see a hole there that needs to be filled. Indeed: > IMO the real challenge (apart from consistent > implementations of MI and MD) are dynamic types marshaled between the parts > of a distributed system. I didn't think much about that, so don't expect me > to answer how that should be solved. Probably others might have some > insights... I guess this challenge is what some here had hoped to learn about. You sounded like you knew the solution :-)
From: Dmitry A. Kazakov on 18 Jan 2010 11:41 On Mon, 18 Jan 2010 16:21:53 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: >> On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote: >> >>> (3) adding subs to T to accomodate specified processing needs >>> of another, later program? How? >> >> By conversion of the object to another type: >> >> X : Integer; >> Y : Float := Float (X); -- Now we have sin, cos etc > > This conversion of a (then) persistent Integer object > to a Float object is possible because either type is known > (and can be named). You cannot have object of an unknown type. > The meaning of conversion from Integer > to Float is language defined, too. Type-defined. Conversion of concrete types is a doubly-dispatching primitive operation. Ada 83 didn't have dispatching operations and MD is still > What a persistent O-O storage would have to offer is something > in addition. > > In Toulouse: > > X : Private_Type_A; > begin > OO_Store.Put(X); > end; Put (OO_Store, "Some name", X); I prefer this notation, because this operation also is doubly-dispatching. > Then, where Identity is an identifier, or the object, or > a handle, or a filename, or ...: > > Pass(Identity(X), From => Toulouse, To => Hamburg); Rather: Put (OO_Store, Locate ("Hamburg") & "Some name", X); you do not need to pass anything. Store it where it belongs to. The main idea is that imperative I/O is normally not needed. "Pass" is disguised I/O. > In Hamburg: > > Y : Private_Type_B; > begin > OO_Store.Get(Y [, <from the identity>]); > > How is Hamburg enabled to learn what Toulouse.Private_Type_A > is with the persistence layer functioning as the only source of > information about the object? In this case from some information outside: Y : Interested_In'Class := Get (OO_Store, "Some name"); > Which operations does it support? Of the class. When you create Y in your program you know what you are going to do with it. That is described by Interested_In. This is no different from knowing its name "Some name". This is a-priori knowledge. For example, a compiler expects an Ada source file. > What kind of conversions are possible, what granularity of > access to the object's innards might be needed to reify > the interface of Hamburg.Private_Type_B? There is a common ancestor for both types. What you probably had in mind was a conversion is between types from independent hierarchies rooted on different hosts. That normally should not be needed. To me the problem rather is in passing the concrete type of Y, which the program will never have to learn, but the run-time must. It will modify the dispatching tables, take the implementations of overridden operations in the form of some byte code (?) etc. >> IMO the real challenge (apart from consistent >> implementations of MI and MD) are dynamic types marshaled between the parts >> of a distributed system. I didn't think much about that, so don't expect me >> to answer how that should be solved. Probably others might have some >> insights... > > I guess this challenge is what some here had hoped to learn > about. You sounded like you knew the solution :-) I am sorry, then. There are hundreds of well paid people sitting in universities studying and teaching OS'es and distributed systems. Why are you asking me? Ask Andy Tannenbaum! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 18 Jan 2010 12:17
Dmitry A. Kazakov schrieb: > There is a common ancestor for both types. What you probably had in mind > was a conversion is between types from independent hierarchies rooted on > different hosts. That normally should not be needed. Well, I learned from the discussion that independent roots of blobs' types it is a quite common case. In fact, it is the very cases on which the objections were based. > To me the problem rather is in passing the concrete type of Y, which the > program will never have to learn, but the run-time must. It will modify the > dispatching tables, take the implementations of overridden operations in > the form of some byte code (?) etc. Right. The modifiable dispatching tables are the interesting part or an O-O file system. I guess that CORBA and Microsoft CORBA (.NET) may offer some hints. |