home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3831 < prev    next >
Encoding:
Text File  |  1993-01-13  |  1.7 KB  |  46 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!starnine!mikeh
  3. From: mikeh@starnine.com (Mike Haas)
  4. Subject: Re: Documenting - blocks source to target
  5. Message-ID: <C0rzKE.8nK@starnine.com>
  6. Sender: mikeh@starnine.com (Mike Haas)
  7. Date: Wed, 13 Jan 1993 04:38:37 GMT
  8. References: <1ijtaoINN3m4@usenet.INS.CWRU.Edu>
  9. Organization: StarNine Technologies, Inc.
  10. Lines: 34
  11.  
  12. In article <1ijtaoINN3m4@usenet.INS.CWRU.Edu> bs764@cleveland.Freenet.Edu (Fred H Olson) writes:
  13. > 
  14. >In a message about blocks vs text files cbbrowne@csi.uottawa.ca
  15. >(Christopher Browne) states:
  16. > 
  17. >>In the case of an embedded controller, there may not BE anything
  18. >>connected in the end, aside from an RS-232 connection.  In this case,
  19. >>"streams" win out, since there is nothing that even resembles a BLOCK.
  20. >>I think that EForth works this way.
  21. > 
  22. >   Blocks can work fine here without going to 'serial block
  23. >emulation'. It is trivial to send blocks as a stream...  (Not so
  24.  
  25. >  One feature
  26. >of such a system was that the host could filter the blocks before
  27. >sending them -- not sending 'trailing spaces' or anything after a
  28. >;S on a block for example. 
  29.  
  30. This is what kills me about blocks... the above fella used -TRAILING when
  31. sending screens over a communications media, adding extra code to both
  32. the SEND and RECEIVE routines  (the RECEIVEr has to put them back in, no?).
  33.  
  34. Why is he not concerned about the terrible waste of disk space that
  35. SCREENS cause?
  36.  
  37. In short, he did extra work to efficiently transfer his source from one
  38. place to another, but once it got to the other end, he has to do more
  39. work to cause his source code to (once again) take up much more disk space
  40. than necessary.
  41.  
  42. Go figure.
  43.  
  44. Blocks just don't make sense.
  45.  
  46.