ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) (10/15/90)
Rick VanNorman writes: >I propose using a virtual program page model for files -- each page >being roughly equivalent to an almost free-format block. The limits on >page size are arbitrary, but a size equal to one printed page seems >reasonable, say 80 columns by 60 lines (4800 bytes). Writing a page >editor such as this is relatively trivial; although not quite as easy as >a block editor, it is still within the range of a 4K byte extension in >most Forth systems. Text could be imported into the editor from normal >Ascii files -- the import procedure would take tabs, crlf, etc., and >put them into the fixed size buffer, with all white space occupying a >character position just like in blocks. Editing would be simplified by >this model, with the only major extension over block editing being the >requirement to scroll the visible portion of the page up and down. I actually proposed something of this sort to the ANS TC a couple years back (the proposal was shot down in flames, not unexpectedly). My proposal called for two User Variables: BLKSIZE and RECL for block size and record length, where the condition BLKSIZE RECL MOD 0= had to be true (i.e., the record length had to be an integral divisor of the blocksize). Then, the amount of storage retrieved by BLOCK was determined by BLKSIZE, and RECL could be used to determine record boundaries in an editor. In support of this concept, I rewrote my editor so that it correctly displayed and edited files of any blocksize. It was trivial to do, and I now had the best of both worlds: unlimited file size and superior edit-compile-debug loops from blocks, and reasonable layouts by setting RECL=80 and BLKSIZE=2000 (80*25). My reasoning came from recognizing that blocks for source code were simply 64-byte fixed-length records in a 1024-byte blocksize, and there wasn't any really good reason to restrict it this way in this day and age. Like I said the TC never even really gave this one serious thought and they were probably right. Anyway, it was real easy. I don't think you need any set of conventions like you describe to make a reasonably-sized block system compatible with a text-file system. Our block editor had block split, block join, block insert block delete, block swap, and block copy. With all that stuff, shuffling code was *easier* than with any text editor I've used since (and I've used a lot of them under six different operating systems). You can just load a text file into the block editor like you described, write it as a block file during code development, and convert it back to text when the program is finished. One advantage not mentioned in the block-vs-text battle that I really appreciated on small systems was a file size limited by the available mass storage, rather than memory. An Apple // only had 20-30K of free space at any one time, and with block files I could just as easily edit a 5-block file as a 100-block file. Of course, on larger systems -- even PCs -- this is less of a consideration. -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM Internet: zmleb@scfvm.gsfc.nasa.gov -- "Between an idea and implementation, is software." -- Curse from Hubble -- Space Telescope engineer.
jax@well.sf.ca.us (Jack J. Woehr) (10/18/90)
ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) writes: ... stuff ... >any one time, and with block files I could just as easily edit a 5-block file >as a 100-block file. Of course, on larger systems -- even PCs -- this is >less of a consideration. Amen, Bro. Lee ... also, BLOCK files are the *only* truly universally portable file format in existence! I read Forth screens intended for ANY system with ANY of the twenty or so Forths that I use with no conversion. <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\
rob@innovus.UUCP (Rob Sciuk) (10/20/90)
In article <21231@well.sf.ca.us> jax@well.sf.ca.us (Jack J. Woehr) writes: >ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) writes: > > ... stuff ... > >>any one time, and with block files I could just as easily edit a 5-block file >>as a 100-block file. Of course, on larger systems -- even PCs -- this is >>less of a consideration. > > Amen, Bro. Lee ... also, BLOCK files are the *only* truly universally >portable file format in existence! I read Forth screens intended for ANY system >with ANY of the twenty or so Forths that I use with no conversion. > > ... stuff ... Yet another fool ... into the breach ... (not them -- me!) WHY COMPROMISE? HAVE BOTH!!! Yes, I have yet another homebrew implementation written in C, and designed to be HOSTED UNDER ANY OPERATING SYSTEM. Currently it runs under DOS, Un*x, MPE V, and MPE XL on a number of different hardware architectures. It is desirable to be able to READ/WRITE/COMPILE/EDIT the operating system's favourite file types whether they are fixed length, variable length, terminated etc etc. BLOCK files are indispensible for writing portable DBMS applications, memory extensions and all the neat things that a proper BLOCK file implementation allows: Forth-83 words: BLOCK, BUFFER, UPDATE, SAVE-BUFFERS, FLUSH in addition non standard words: CREATE-FILE ( strptr len --- fptr ) OPEN-FILE ( strptr len --- fptr ) ASSIGN-FILE ( fptr --- ) WHICH-FILE ( --- fptr ) DELETE-FILE ( fptr --- ) CLOSE-FILE ( fptr --- ) which allow access to block files. Further, just three words allow use of C stream files as implemented in the environment: LOAD ( strptr len --- ) a non-standard word which redirects standard input from the file named in the quoted string on an input file stack N files deep. (eg: " myfile" LOAD ) My apologies to the purists who do not like non-standard WORDS, but its MY Forth, and I'll implement what I like! OUT ( strptr len --- ) a non-standard word which redirects standard output to the file named in the quoted string and pushes the file onto an output file stack N files deep. eg: " myfile" OUT NOOUT ( --- ) closes the current output file and pops the file stack. Thus I use text files for compiling, and editing source code with the system editor, and BLOCK files for use within applications. IMHO a flexible and rational combination of the two methods FOR THOSE SYSTEMS WHICH RUN UNDER A HOST OPERATING SYSTEM. rss.
jax@well.sf.ca.us (Jack J. Woehr) (10/22/90)
rob@innovus.UUCP (Rob Sciuk) writes: (re BLOCK vs TEXT files) >WHY COMPROMISE? Why not have them both? Exactly, Rob, that's precisely what the BASIS for ANS Forth proposes. You can download your copy of the present level of BASIS revision (BASIS13) from GEnie Forth Interest Group RT or may receive the official printed document by mail by sending $10.00 to ANS X3/X3J14 Technical Committee 111 N. Sepulveda Boulevard Manhattan Beach, CA 90266 <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\