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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-08-28 09:13:40 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!news-east.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com.POSTED!not-for-mail Message-ID: <3B8BC332.214F95CA@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS References: <9IFe7.12813$6R6.1221214@news1.cableinet.net> <9lghqu$ac6$1@nh.pace.co.uk> <3B7C3293.76F49097@home.com> <9lhefg$lgd$1@nh.pace.co.uk> <3B7D47F1.25D6FC78@boeing.com> <5ee5b646.0108171856.18631c4c@posting.google.com> <3B7F624B.7294D24F@acm.org> <9lr6je$5hj$1@nh.pace.co.uk> <9ltoi7$4is$1@nh.pace.co.uk> <3B82789B.8D195045@home.com> <9ltuo8$70n$1@nh.pace.co.uk> <3B829450.879B0396@home.com> <9mdh4e$q3v$1@nh.pace.co.uk> <9me03r$c302@news.cis.okstate.edu> <3B8AB6C8.910130C8@san.rr.com> <9metfo$aai2@news.cis.okstate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 28 Aug 2001 16:13:42 GMT NNTP-Posting-Host: 24.165.20.229 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 999015222 24.165.20.229 (Tue, 28 Aug 2001 09:13:42 PDT) NNTP-Posting-Date: Tue, 28 Aug 2001 09:13:42 PDT Xref: archiver1.google.com comp.lang.ada:12521 Date: 2001-08-28T16:13:42+00:00 List-Id: > That would be why objects, processes and RPCs aren't files. Why not? Again, you're starting with a preconceived notion of "file" being "an array of bytes", then claiming that the OS should be handling that as the basic type. Indeed, RPCs *can* be files. It's called a CGI script. Objects can be files. It's called an OO Database. Processes can be files. It's called /proc. Etc. Open your miiiiind.... ;-) For example, on the Amiga OS, files were tasks, as were device drivers, etc. You could send a message to a file task to read and write portions of the file into particular buffers, and when the message returned, the I/O was complete. This allowed you to treat windows as files (open("con:top/left/width/height/title")) and such. It allowed you to write phenomes to the voice synthesizer and read lip positions back as the sound was generated. Cool stuff like that. Imagine an OS where "files" are actually protected objects, fully typed, that outlive your program's execution. Directories are simply persistant protected objects that act as arrays mapping strings to these "files". > > If there were an AdaOS that didn't allow one to declare a passive > > partition and say "Hey, this is the data", I'd be disappointed. Why > > *can't* my "file" have a directed acyclic graph of tagged records > > holding access values in it? > > An OS could certainly flatten that into a file. It would probably > take a lot of work to make sure it wasn't an OS/program/libada specific > file, though. I don't see any particular need to flatten it as such. Again, you're trying to map "files" onto "array of bytes in a UNIX-like file system". That's not the point. > >> Everything can viewed as raw data. > > > > Well, no. Only if you come from the Unix/Windows/CPM world. (Not even > > there, actually. What's the "raw data" in the superblock? In a > > directory? In a network-mounted partition?) > > Those aren't files. My point is to ask why not. My point is to ask "why limit yourself to array-of-byte files" and you're answering "because anything else is not a file." That's not helpful. > > Those of us who had the privledge of (for example) using ISAM files so > > you could actually insert a line of text at the beginning of your file > > without rewriting the whole file can tell you that not everything is raw > > data. :-) > > When is that much of a win? I don't play around with files large enough > for this to matter very often. Put it this way. Let's say files were just numbered in a directory, rather than having meaningful textual names. When you deleted file 5, all the files from 6 up to whatever got renumbered. Is it reasonable to say "why's that a problem? I only work with small directories." There's a reason folks put names on files, on procedures, on users. The same reason holds for individual pieces of data in a file. It's a win whenever you store more than one piece of data in a file, like more than one line in a text file, more than one user in a password file, etc. And if you're only storing one atomic piece of data in a file, it's because you're using the file's name as an index anyway. Have you never written a program where the name of a file is calculated by the program? "Image01.jpg", "Image02.jpg", ...? And yes, it *is* a problem for large files, or folks wouldn't have invented the DBM stuff to hold /etc/passwd in a hashed file, and they wouldn't have rewritten directories to no longer be linearly searched. Same thing. If you've never used a system where there are keys on the data records, you might not understand why it's useful. On the other hand, if you've only ever used FORTH, where the disk is organized as a numbered array of sectors, you might not appriciate the charm that having directories and file names supplies. > > The type for an "Active Server Page" with Ada code embedded in > > HTML markup under control of CVS? > > text/x-asp. And how does CVS know it can handle this, and how does the web browser know it needs to invoke the Ada compiler and not the Java compiler when rebuilkding this page? > > And how do you determine which > > programs can read such? :-) > > Any program that can read raw data, or text, or text/ada. > > I'm not sure I understand your point. These are problems for all > tagged type systems, but you don't seem to want raw data either. The point is that no passive tagging system is going to be complete enough that you can specify everything you need to know about the program in the type tag. Just like every permission system needs something along the lines of setuid to let you do very specific things with very specific files that you otherwise couldn't do. My point is that a persistant data storage system modelled as named arrays of bytes is just primitive. The addition of type tags tells you what library to use to understand the interpretation of the untyped array of bytes, which is just silly when you start trying to use it from a language like Ada that actually has real types. > It's always the device drivers. Even in MS/DOS, copy called the OS to > actually write the file. But if the mac box looks like a directory to > copy, then copy copies it there, regardless of the underlying mechanism > to put data in that directory. Errr... When talking about designing and writing an OS, saying "oh, don't worry, the device drivers will take care of it" doesn't work. In any case, a program like "copy" can only copy raw data if the raw data is primitive. If, for example, you have semantically significant record boundaries on a tape, and you copy it over TCP, you're going to lose those boundaries. If you have (say) a database file with pointers to disk blocks embedded in it, and you copy that file to another place on the disk, you need to fix those disk block pointers. Etc. > > Anyway, I'd think making a persistant Ada-typed store would be a great > > file system for an Ada-based OS. Then you could have utilities to copy > > Text_IO-based files to whatever internal format you wanted (such as > > "editable text"). > > Yuck. Text_IO files should _be_ editable text. Text should be text should > be text. Text_IO files aren't editable. There's no way to (say) insert text at the beginning. There's no way to change text in the middle. Nobody writes a text editor (at least under an array-of-characters file system) that doesn't suck the file into a different data structure for editing and then write it back out. That different data structure is what I'm talking about. Why not make *that* persistant, and have Text_IO be the "portability" level. I.e., why insist that "stream" are the "real" data, and everything else is just this temporary copy inside a program? Why not let the real data be the one with the pointers and strong types and such, and only use streams when you want to communicate with a different OS? -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand.