ForthNet@willett.UUCP (ForthNet articles from GEnie) (04/09/90)
Category 10, Topic 6
Message 34 Sun Apr 08, 1990
F.SERGEANT [Frank] at 12:20 CDT
There have been some recent messages about converting block files to text
files. Some C program solutions have been presented. This seems especially
appropriate to me, as I think someone with a C bent would be more likely to
want the block files converted.
Be that as it may (as my grandmother would say), it is easy to do the
conversion in Forth. This is very easy in Pygmy which allows easy access to a
number of files at the same time. It should be do-able in F83 which allows
access to an output file & an input file (see OPEN & FROM).
Here's one approach just to illustrate the idea. As usual this is
untested, although I have used similar code successfully on several occasions
(not that I have a C bent, you understand).
VARIABLE OUTPUT-POINTER
VARIABLE STARTING-OUTPUT-BLOCK#
: C@+ ( a - a+1 c) COUNT ;
: TEXT! ( c -)
OUTPUT-POINTER @ 1024 U/MOD ( c offset-into-blk relative-blk#)
STARTING-OUTPUT-BLOCK# @ + ( c offset-into-blk absolute-blk#)
BLOCK + ( c a) C! ( ) UPDATE 1 OUTPUT-POINTER +! ;
: LINE-TO-TEXT ( a -)
64 -TRAILING ( a #) FOR C@+ ( a+1 c) TEXT! NEXT DROP ( )
$0D TEXT! $0A TEXT! ;
: BLOCK-TO-TEXT ( blk# -)
BLOCK ( a)
16 ( ie #lines-per-screen)
FOR ( a) DUP LINE-TO-TEXT 64 + NEXT DROP ;
: BLOCKS-TO-TEXT
( from-1st-blk# from-last-blk# starting-output-blk#)
OUTPUT-POINTER OFF STARTING-OUTPUT-BLOCK# ! ( 1st last)
OVER - 1+ ( 1st #)
FOR ( blk#) DUP BLOCK-TO-TEXT 1+ NEXT DROP FLUSH ;
Note in the above that 7 FOR ... NEXT would loop 7 times and that 0 FOR ...
NEXT would bypass the loop altogether. You will have to adjust the code if
you are using the more common FOR NEXT or if you are using DO LOOP.
However, to speed it up if space permits, or if you have trouble accessing
more than one file at a time, you could build the output file in RAM and then
write it all at once to disk (Pygmy's MSAVE or F83's SAVE). Another approach
I've used is to write a word to call DOS to write one char sequentially to a
file.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'wmb@MITCH.ENG.SUN.COM (04/09/90)
> it is easy to do the [block source to text file source] conversion > in Forth. Not strictly true. A more correct statement would be: It is easy to do it in some Forth systems which provide file access, but there is no *portable* way to do it in standard Forth. (I am speaking here of existing Forth systems; the ANS Forth document provides the necessary functions to do it portably). Mitch
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/11/90)
Date: 07-04-90 (13:45) Number: 435 (Echo) To: GARY SMITH Refer#: 434 From: RAY DUNCAN Read: 07-06-90 (19:15) Subj: BLOCK VS TEXT Status: PUBLIC MESSAGE The implementation of SOURCE that Mitch describes is better than the traditional source stream logic but still relatively inefficient. In LMI systems, the source stream itself is cached on a block-by-block or line-by-line basis before INTERPRET is called. Each time WORD executes it merely needs to use the 2EQU SOURCE (which functions like a 2CONSTANT to provide the base and length of the input stream) and >IN to parse off the next token. Nothing inside the INTERPRET loop ever looks at TIB, #TIB, or BLK at all. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 Date: 07-04-90 (13:47) Number: 436 (Echo) To: GARY SMITH Refer#: 434 From: RAY DUNCAN Read: 07-06-90 (19:15) Subj: BLOCK VS TEXT Status: PUBLIC MESSAGE Incidentally, LMI supports compilation from either text files or from BLOCKs, and also provides utilities to convert one to the other. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/13/90)
Date: 08-04-90 (14:55) Number: 657 (Echo) To: GARY SMITH Refer#: 616 From: ZAFAR ESSAK Read: 08-09-90 (22:32) Subj: THOUGHTS ON FORTH Status: PUBLIC MESSAGE > This leads me to a side point. Which is more fundamental? That is > which is more appropriately "built from" the other? > A sequence of 1024 byte blocks, or > A stream of bytes. > Conceptually, the stream of bytes seems more fundamental because it > is more general. Practically, blocks seem better matched to the > underlying media. Of course, that is only an ephemeral match that > will last so long as the media technologies are like they are now. It appears to me that you have already answered the question by the way you have phrased it. Assumption #1. The concept of a stream of bytes is the fundamental representation of human thought and information. Assumption #2. Blocks are the most efficient means of access to the storage media of current technologies. Conclusion #1. Therefore, blocks should be the interface to the hardware and streams should be the interface to the humans. Corollary #1. As technologies change, more efficient methods of access to the storage media may be developed and replace blocks. Corollary #2. The Stream approach will remain as the fundamental user model until such time as our understanding of human thought and information changes. ============================================== From my experience I would support Assumption #1. From the experience of others as voiced on the Forth Net it appears that assumption# 2 may also be true. Zafar Essak. --- * Via Qwikmail 2.01 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-25-90 (14:00) Number: 3855 (Echo) To: ALL Refer#: NONE From: CHARLIE HITSELBERGER Read: HAS REPLIES Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE I realize that this is probably asking a question about a great debate that has already been waged here, but I wasn't here then, so I am asking. What is better, Blocks or files? (for editing source, that is) I think I know why Chuck Moore used blocks. It was closer to the bare metal, easier to get an editor flying, totally generic, and about the size of a screen. Personally, I am more comfortable writing vertical code, with nested control structures and all that. Moreover, the hardware that I most frequently run Forth on does not have the 64-column by 16-line video hardware that a Forth block expects to be displayed on. It is actually 40 columns by 25 lines. I am sure all you PC guys were a little disappointed that the standard didn't call for an 80 by 25 block! Then there's the issue of all that wasted blank space when you use blocks. And then there's the "both!" school of thought. I am leaning closer to this one. Have blocks as the baseline but at least add in an "FLOAD" word (or sovwwww @mething similar) to an extension set. Anybody's comments on this will be most appreciated. Tastes Great! Less Filling! Tastes Great! Less Filling! Blocks! Files! Blocks! Files! ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-26-90 (00:25) Number: 3856 (Echo) To: CHARLIE HITSELBERGER Refer#: 3855 From: DAVID BREEDING Read: 09-26-90 (11:23) Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE Actually, the way F83 handles blocks vs files is the best I've found. That is, it allows you to open files that are subdivided into 1k blocks. That way you use blocks still, but you've got files you can open, edit, and move around just like any other file. However, back to the original argument. C. Moore picked blocks for 2 reasons, one they are divided into equal 1k blocks (which makes them easy to find, print, and colate), and it is a way to insure consise programming. When people use editors they tend to run all over the place, starting 2 orr3 spaces over, commnets in different places, ect. With blocks you have a set structure which you can not change, therefore everything looks pretty much the same. I think blocks are GREAT!! Anyone who has ever looked through a 20 page Forth editor file can attest to the fact that they are A LOT harder to follow... Nuff said... ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 10-01-90 (03:55) Number: 3949 (Echo) To: DAVID BREEDING Refer#: NONE From: DEAN MARTINDALE Read: NO Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE I have used blocks in Forth for quite a while, and thought they were the way to do it!--until I started using files. Now I consder blocks to be an outdated concept. A poorly designed program is a poorly designed program, whether written in files or in bocks. In readin several years of Forth Dimensions source code, I didn't notice any great legibility in the blocks jam-packed wit arcane Forth code. More often than not I would just skim over the code and not even try to understand it because it was a mess.(Please fn F.D.! Some of the code was good, and you KNOW I'm talking abut yours!) I consider blocks to be excessively restrictive, while providing dubious advantages at best. In this day and age ofwidespread software crisis, we programmers need as few obstacles as possible in the development cycle. PCRelay:FORTHNET -> RelayNet (tm) NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
heron@mars.jpl.nasa.gov (Vance Heron) (10/06/90)
> From: CHARLIE HITSELBERGER Read: HAS REPLIES > Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE > > What is better, Blocks or files? (for editing source, that is) > IMHO files are *much* better - I used a few of Bradleys forths - both under VMS & UNIX, but I also had the pleasure of introducing forth to several non-forth programmers - I had a fair amount of resistance, but I think blocks might have ended the entire affair - almost everyone who has ever used a computer knows how to edit files (and has their own favorite editor too) - with a simple (to use anyway) escape to the host OS, you can let everyone use any editor they want - they can insert as much code as they want, wherever they need it - and the Bradley forth's I used allowed you to LOAD <filename> - what could be easier ?? We could also have a main load file that just loaded all the others - to print the entire source do a global edit and change the LOAD command to PRINT and submit it to your local OS ! Happy Campers !! Also - in reply to another poster complaining about style, indentation, comments,... We all found text files to better accommodate "structured" formatting of the input data - and allowed easier printing of the code - vs - how many blocks for function 'X' ... > Tastes Great! Less Filling! Tastes Great! Less Filling! Blocks! > Files! Blocks! Files! probably true - unfortunately - these arguments/discussions seem rather religious :-( ------------------------------------------------------------------- Vance Heron | "Nothing sucks like a VAX" heron@mars.jpl.nasa.gov | - from a SEARS commercial -
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Date: 10-10-90 (18:50) Number: 5 of 10 To: MICHAEL HAM Refer#: NONE From: CHRIS WATERS Read: NO Subj: Blocks And Files Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) MH/I know one programmer on the PC who writes in Forth with Sidekick MH/and uses Sidekick's memory-resident program as his program editor But it would be nice to be able to have the system show you where an error occured, as you easily can with a block editor. Not to mention things like being able to continue a compile after an error without recompiling all the code that came before. A file editor in Forth still seems like it would be the best solution. The first Forth I ever used (back around '77-'78) actually came with a line editor -- it didn't have blocks. This was _before_ Fig-Forth! The main problem it had was that the file size was limited by available memory. And of course, as your application grew, the amount of memory available for the file decreased. With larger machines and more memory, editing in memory might not be as much of a problem as it was back then. This would require either a large model (32-bit) Forth or non-standard addressing (e.g. seg:offs on the 80x86), which would limit the portability. Best would be an editor limited by disk space, not by memory. But can a decent editor like this be written in only a couple K of standard Forth? It would have to be only a few K to seriously compete with block editors. Trying to write such a beast is one of those projects I keep putting off. I'm not sure how feasible it is, but until something of the type is available, I'll probably stick with blocks. Much as I would like to switch... MM 2.1a *Shiva is a punk rocker! --- * SFUTI 3.01 / (Pssssst.....Mikey's really not 29 anymore....) PCRelay:THECAVE -> #559 RelayNet (tm) 4.10 The Cave (408)259-8098 12/24/96/19.2 HST/DS ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Date: 10-11-90 (17:51) Number: 6 of 10 To: PETE KOZIAR Refer#: NONE From: ELLIOTT CHAPIN Read: NO Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) PK>F-PC on the IBM PC is strictly text-file based, yet allows both But there are block words. Elliott Chapin --- ~ DeLuxe} #4315 ~ PCRelay:CRS -> RelayNet (tm) 4.10a14 Canada Remote Systems * Toronto, Ontario ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Date: 10-12-90 (14:45) Number: 7 of 10 To: MICHAEL HAM Refer#: NONE From: IAN WATTERS Read: NO Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) MH=>I know one programmer on the PC who writes in Forth with Sidekick loaded =>and uses Sidekick's memory-resident program as his program editor: the =>code goes into text files edited with Sidekick, with the editor just a =>hot-key away. Now you know two! What would we do without Forth and Sidekick? Ian --- ~ SLMR 1.0 ~ I think he likes it! ~ TomCat! 2.5 w # Via ------>IBBSNET In London England ---------> PCRelay:IBBSNET -> #143 RelayNet (tm) 4.10a15 <Islington BBS> London UK +44 71 704 0760 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Category 10, Topic 6
Message 46 Sun Oct 14, 1990
F.SERGEANT [Frank] at 20:04 CDT
MB> I think it is funny when people claim that blocks enforce ...
I may not agree with you in every respect about every thing, however, I
too have felt it is ridiculous to use as an argument for blocks that they
constrain you in some way. As you point out, it is especially inconsistent
to use such an argument in **Forth**!
I suppose Dashiell Hammett is my favorite author of all time. Here is a
quote from Ryerson Johnson, who attended a writing class by Hammett, quoting
Hammett:
Hammett slammed his hand down flat on the table,
glared around the room in what seemed hopeless despair.
"Oh, for Christ's sake," he said. "Go home and write
your story any goddamn way you want to."
That is just about my attitude these days on whether programs should be
written in blocks or text files.
Personally, I'm still, fairly happily, using blocks for Forth source.
It is all I've used except for brief experiments. I don't consider it a
closed decision, though. Blocks don't completely suit me, especially for
CODE definitions, but so far they suit me better than text files. I've
speculated that the editor is the overriding factor, rather than whether the
source is in blocks or text files. Mine's fairly comfortable, with the
ability to spread open to insert new blocks, and squeeze out empty blocks. I
look forward to doing some more experimenting in this whole area of managing
source code.
(On the other hand, I've done a lot of programming over the years in a
variety of languages using text files with everything from line editors to
full-screen editors, with the exception of EMACS. I gather it has some
strong points, but I haven't yet grasped what it is all about.)
Maybe source code should be managed in a system that looks something
like an outline processor, where we can easily shift levels and hide or
expose details. This might be called a hierarchical, variable sized block
system.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwptoma@tekgvs.LABS.TEK.COM (Tom Almy) (10/15/90)
In article <1860.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: > Maybe source code should be managed in a system that looks something >like an outline processor, where we can easily shift levels and hide or >expose details. This might be called a hierarchical, variable sized block >system. An interesting point. There was this CP/M program called KAMAS which was an outline processor with an interesting feature: it was also a Forth-like (really STOIC-like) programming language. You could load KAMAS code from the outline structure. You specified a node in the outline tree, and it would do a depth-first traversal loading code. While nicer than flat files, it still wasn't good enough because programs aren't really tree structured -- they are really more like directed nets (witness that the word "@" is likely to be used in most low level nodes). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply P.S. I found KAMAS so appealing that it was the last application I continued to use before giving up on the CP/M environment. An incredible program.
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (10/16/90)
In article <1859.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: > MH=>I know one programmer on the PC who writes in Forth with Sidekick loaded stuff deleted > Now you know two! What would we do without Forth and Sidekick? Try Amiga Multi-tasking window OS, 1 or more JFORTH's and a REAL Editor or two!
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Date: 10-06-90 (23:18) Number: 3975 (Echo) To: DEAN MARTINDALE Refer#: 3949 From: DAVID BREEDING Read: NO Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE Ok, as I've stated here before...I think files are a GREAT improvement over the 'starting forth blocks' way of dividing up disk space. However, I must disagree about the use of blocks. Now granted, if you have it all printed on paper files are better and more readable. But if you're working on a program in memory, blocks are easier to work with. For instance...with CPM F83 loaded into my system I can request the source of ANY word (view command). This allows me to see not only the code (which can be done by decompiling) but also my comments and such. This can not be done with text files, and until I can get a editor that I can call and use from wthin Forth itself, I'm not about to go switching back and forth between the editor and forth (that's the reason I hate C). In short, blocks are a good comprimise. You can only see about 1 blocks worth of information at a time anyway, so it only makes since to show one screen of information at a time. Blocks is just the best way (as of right now) to do it. If a better way comes along, I'll be the first in line... ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Date: 10-07-90 (11:42) Number: 3995 (Echo) To: DAVID BREEDING Refer#: 3975 From: MICHAEL HAM Read: NO Subj: BLOCKS AND FILES Status: PUBLIC MESSAGE I know one programmer on the PC who writes in Forth with Sidekick loaded and uses Sidekick's memory-resident program as his program editor: the code goes into text files edited with Sidekick, with the editor just a hot-key away. One major advantage of blocks is the ability to reload a small portion of the application as one revises and debugs: forgetting and reloading a single block is very quick compared to reloading a complete (long) file. He gets around this difficulty by building his application as many short files, modularized as much as possible. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
wmb@MITCH.ENG.SUN.COM (10/19/90)
> For instance...with CPM F83 loaded into my system I can request the > source of ANY word (view command). This allows me to see not only the > code (which can be done by decompiling) but also my comments and such. > This can not be done with text files Yes it can. I do it every day. I use EMACS, running Forth inside an EMACS buffer. I can either type a word or point to it, type a key, and a window pops up with that word's source code in it. The implementation is no big deal; as the system is compiled, remember the names of the files that are included, along with the value of the dictionary pointer when each file was opened and closed. To locate the source for a word, find it's cfa, locate the file whose dictionary start,end values most closely enclose the cfa, edit that file, and search for the word. Easy and effective; requires a decent editor like EMACS though. By the way, EMACS need not be very large. The version of MicroEMACS that comes with Forthmacs is 26K. It runs co-resident with Forth, and you can pop back and forth with a couple of keystrokes, retaining all the state of both Forth and EMACS. Mitch
pl%VME131.LSI.USP.ANSP.BR@SCFVM.GSFC.NASA.GOV (11/03/90)
Can't I just think that a block is a big line? I see no difference. ========================================================================== Pedro Luis Prospero Sanchez internet: pl@vme131.lsi.usp.ansp.br University of Sao Paulo uunet: uunet!vme131!pl Dept. of Electrical Engineering bitnet: psanchez@uspif1.bitnet phone: (055)(11)211-4574 home: (055)(11)215-6492 fax: (055)(11)815-4272 ==========================================================================
wmb@MITCH.ENG.SUN.COM (11/03/90)
> Can't I just think that a block is a big line? I see no difference.
In some sense, yes. However, there are a few differences:
1) "\" only ignores a portion of that "big line".
2) A text file implies a particular sequence of lines, with a well-defined
end-of-file. The "sequencing" of "block lines" is handled differently,
either with THRU or with "-->". If you try to write a program that
"reads ahead" in its own input stream, you will encounter annoying
"what to do at the end of the line" differences between the block line
model and the text file line model.
Mitch Bradley, wmb@Eng.Sun.COMForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/20/91)
Date: 01-13-91 (22:17) Number: 880 of 891 (Echo) To: B.RODRIGUEZ2 [BRAD] Refer#: 829 From: STEVE WHEELER Read: NO Subj: SOURCE CODE CONTROL Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Here at Vesta we have been using Polytron's version control system (PVCS is a commercial product) for a few projects. We have used it for Forth source in both block files and text files. I like it much, and intend to start using RCS on our non-Messy-Dos systems, but there are a few caveats ... With block files, you can't take advantage of the capabilities to time/date/etc. stamp the files as to when they were taken from the archive, nor can you maintain in the source the revision comments maintained by the version control system. With text files, this may not be a problem (PVCS allows you to specify the comment prefix based on file extension, so "\ " for *.4TH works nicely. We're moving to using it for maintaining revision control on code, documentation, and anything else we keep around and revise. Sometimes, being able to recover a previous version of something (prior to improvements and enhancements which failed) can save a project (or an ass ...) - Wheels NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth! <<<>>> ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp