From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-03 23:13:56 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Robert C. Leif, Ph.D." Newsgroups: comp.lang.ada Subject: RE: Ada OS talk (was: Progress on AdaOS) Date: Mon, 3 Sep 2001 23:11:30 -0700 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 999584035 74786 137.194.161.2 (4 Sep 2001 06:13:55 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Tue, 4 Sep 2001 06:13:55 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:12671 Date: 2001-09-03T23:11:30-07:00 From: Bob Leif To: M. A. Alves et al. I totally agree with, "To that effect I propose a generic principle of simplicity/smallness. That is why my messages have a general "downsizing" tone." However, I suspect that Ada will permit both "simplicity/smallness" and advanced functionality. If a file type is described as a generic private tagged type in the kernel, functionality can be added in the outer layers. Since one of the goals is efficiency, I would try to avoid those class-wide subprograms (methods) that require run-time dispatching. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Sent: Monday, September 03, 2001 1:13 PM To: comp.lang.ada@ada.eu.org Subject: Re: Ada OS talk (was: Progress on AdaOS) > > > Anyway, it *would* be libraries implementing the types of files. > > > > Yes. That is what I meant with "different levels". I still think you > > need a storage element level as a building block for the file types and > > other elaborations. And this would be the role of the kernel. > > Right. The hardware is going to enforce this. But I don't want to reveal > a storage-element level as a building block for directories, for > example. You are thinking Unix again ;-) Dont! Down with directories! That is just a way of grouping files among many others, including file typing, and so also built upon the storage-element level. > > By serialization you mean a (do_first, do_next, end_error) sort of thing? > > No, I mean flattening into something that has to be parsed. > . . . OK. Them it is definitely an outer layer (w.r.t. the kernel). > > I think the best building block is the (un)bounded array of storage > > elements, which is more than this. But of course I may be wrong. > > It's a good low-level building block, but it's not a good higher-level > building block. I think records are good. I think the ability to insert > and delete records is good. I think the ability to have at least one and > maybe many ordered indicies on records is good. I meant the best _low_level_ building block. Then a middle level layer would provide records etc. but this edifice needs bricks. > > > No more than a lack of image types in a kernel means that images aren't > > > implemented in a coherent standard ways. FORTH simply has library > > > routines to handle directories. > > > > My point exactly. > > I'm lost. I don't think we're really talking about image types here. > . . . The point was that _both_ directories and file types are similarly above kernel level, without hindering coherency or performance. Not important an issue really at this point. Hmmm... what point? I would expect this talk would result in a sort of strategic plan for building an OS as a hobby by Adaists. To that effect I propose a generic principle of simplicity/smallness. That is why my messages have a general "downsizing" tone. Remember the fall of the AdaOS. -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150 PORTO, Portugal mob 351+939354002