Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: PYGMY Forth Message-ID: <1506.UUL1.3#5129@willett.pgh.pa.us> Date: 13 Aug 90 03:45:04 GMT Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 97 Category 1, Topic 45 Message 31 Sat Aug 11, 1990 F.SERGEANT [Frank] at 17:31 CDT To Chris Waters (of MetroLink, I think, duh) Your message was relayed thru the an "xFCB" (I assume the East Coast Forth Board), if I understand things now. Thank you for your suggestions. That's just what I wanted to know. I'll plan to revise the glossary along the lines you have suggested. I am thinking of having the *.COM file include more of the loadable utilities so that they'll be ready to go for someone new to Pygmy. Then he can trim off the ones he doesn't need, in order to cut it down to a minimal size again. You have a good point about the Epson codes being more universally useful. Naturally, I have an Okidata printer. I've factored out the printer setup and will try at least to explain in the HELP file how to print to the Epson and how to print out the source code. My feeling is that ver 1.2 is MUCH better than 1.1 but that, at this point, you might as well wait for 1.3. I haven't been completely happy with the file handling (in either 1.1 or 1.2) and have made some substantial changes for 1.3. As it stands now, files no longer have to be opened "in order" - you can have the 1st file use screens 1800 thru 2200 and have the next file use 300 thru 312 and then skip one or more slots and open another file with screens 900 thru 950, and so forth. Now all aspects of file handling is done relative to the files "unit" number. So far I've been pleased with this new approach. It goes something like this: NAMEZ: MYFILE.SCR ( NAMEZ: in a defining word that creates a Forth word that returns the address of its own name. The string ends in $00 so as to be a suitable "asciiz" file name.) FILE-NAME: DATA1 C:\FORTH\WORK\OLD\YOURFILE.SCR ( FILE-NAME: in a defining word that creates a Forth word that returns the address of the following asciiz string.) 3000 MYFILE.SCR 7 UNIT ( plug the name & starting blk# into unit #7) 900 DATA1 9 UNIT ( plug the name & starting blk# into unit #9) Then, whatever you want to do with a file is done with its unit# (or with the block numbers). 7 OPEN ( open the file MYFILE.SCR) 9 MAKE ( create the empty file named YOURFILE.SCR in the C:\FORTH\WORK\OLD\ subdirectory) 100 9 MORE ( extend that file with 100 blank screens) 9 >EOF ( position to end of file) 9 >BOF ( posititon to beginning of file) 9 EXISTS? ( find out a non-zero length file of that name is present) 3000 3050 SETTLE ( make the heavy screens in this range in MYFILE settle to the bottom - the light screen - with only blanks - float to the top) 9 CHOP ( truncate MYFILE.SCR so that all trailing blank screens are chopped off. Compare this to -TRAILING on strings.) Also available are a few words to make sequential file access easier, such as FILE-WRITE ( a #bytes unit# -) ( for sequential file writes) FILE-READ ( a #bytes unit# -) ( for sequential file reads). As I was doing this, I thought "hey, maybe this is similar to the file handling in BASIS. If so, maybe I can be "compatible" with the "standard" at no great mental & emotional cost to myself!" So, I got out BASIS 11 and looked over the file words. Nope! I can't do it. It hurts too much. Maybe I'll change my mind. In the meantime, if you want it, the tools in Pygmy 1.3 will let YOU do it. Maybe I'm wrong and maybe I'll come around, I don't know yet. After I got the file handling changed around and a few other things, I got interrupted by real work. This is delaying ver 1.3 slightly, but I'm using the new Pygmy, so this gives me a chance to exercise it. Really about the only thing I dislike concerning BLOCKs for source code is for CODE words. High level words seem to fit nicely in a block, but some of the longer CODE words, where the assembly language is a little obscure to begin with, and extensive comments are especially important, MUST spread across a number of blocks. I have no real solution for this yet except "be neat, and put in those comments, and spread across as many screens as it takes." Am I leaning toward variable length, CRLF delimited, line-oriented, sequential files for source code? I don't think so, but ... Emotionally, I am leaning toward the-entire-disk-is-one-BLOCK-file. I'd still keep SETTLE and COPIES but almost all the rest of the file handling could disappear! I don't see any way in H.ll to do it, though, as I am "forced" to co-exist with DOS. If I see a (pretty) way around this, BANG! goodbye DOS. (I don't envision any such changes for ver 1.3, though.) -- Frank ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us