home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3123 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.6 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!math.fu-berlin.de!informatik.tu-muenchen.de!pazsan
  2. From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Block versus file
  5. Message-ID: <1992Sep14.175419.20951@Informatik.TU-Muenchen.DE>
  6. Date: 14 Sep 92 17:54:19 GMT
  7. References: <dak.716483390@messua>
  8. Sender: news@Informatik.TU-Muenchen.DE (USENET Newssystem)
  9. Organization: Technische Universitaet Muenchen, Germany
  10. Lines: 39
  11. Originator: pazsan@hphalle5g.informatik.tu-muenchen.de
  12.  
  13.  
  14. Well, I have thougth quite a long time about the screen vs. stream
  15. problem. I do not agree withsome of David's points.
  16.  
  17. DK>Any block structure imposed artificially on the
  18. DK>top of the file system will be SLOWER than fully utilizing the
  19. DK>file system.
  20.  
  21. Almost every file system HAS a block structure below it, and in many
  22. cases, blocks are a 2^n bytes chunck with n integer and n<=10. So reading
  23. a Forth block (1K) is straigt forward, unbufferd and faster than
  24. arbitrary reading (while "arbitrary" means: less than block size). Even
  25. for my stream file interface I read and write blocks of 2^n bytes (where
  26. n depends on what I found useful). With scanning for line ends stream
  27. file interpretation is SLOWER than block file interpretation, although
  28. less blocks are to read. Now, it's not much slower, so it doesn't hurt.
  29. (and don't blame my scanner: I get 80 000 nl/min through it).
  30.  
  31. The editor problem: One feature of my Forth (and of F83) I like very
  32. much is VIEW. Now VIEW from Forth to an external editor is easy. But I
  33. don't like to leave my editor while I do edit compile debug. So I have
  34. an editor window, a dialog window and I can do VIEW out of the editor
  35. (and eventually open a new window). If you do incremental coding,
  36. Screens are very nice. You can load each screen seperate. Files tend to
  37. grow, screens are limited (the average stream file is about 200 lines
  38. long in my system). And there is another nice feature: consistence. If I
  39. edit and load from the forth window, I don't have to care about saving
  40. (I should save if I crash the system, either). If I edit and load a text
  41. window, I have either to load from the text buffer (requires strictly an
  42. embedded editor) or I have to save (I must remember).
  43.  
  44. So summarize: I tend to convert complete source into stream files,
  45. because they are smaller and most screens are nearly full, so if I had
  46. to do small changes, I have room to expand. And I tend to do very small
  47. things in stream files, too, because small stream files feel like one
  48. screen (and they don't waste screen 0).
  49. -- 
  50. Bernd Paysan
  51. "Keep it stupid simple!"
  52.