home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / hypercar / 4283 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  3.9 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!uknet!mcsun!sunic!seunet!dada!ianf
  2. From: ianf@random.se (HyperAgent In Disguise[tm])
  3. Newsgroups: comp.sys.mac.hypercard
  4. Subject: Re: Importing/accessing text files (repost)
  5. Summary: real programmers do it with variables
  6. Message-ID: <a736467f@random.se>
  7. Date: 23 Nov 92 07:27:47 GMT
  8. References: <jhunix.1992Nov18.164034.15856>
  9. Organization: random design -- "Opinions, cheaply"
  10. Lines: 87
  11. X-Mailer: Fernmail 1.2b2f
  12. Apparently-To: rnews@sunet.se
  13. X-More: Cc: <ianf@random.se> to any public reply that you may post
  14. X-Note: First validated setext browser has now been released and may be
  15. X-This: found in sumex-aim.stanford.edu::/info-mac/app/easy-view-21.hqx
  16.  
  17.  
  18.   crawford@jhunix.hcf.jhu.edu (James E Crawford) writes on (18 Nov
  19.   92 16:40:34 GMT):
  20.  
  21. > I would like to thank everyone for their help in solving this
  22. > problem.  Your assistance has been invaluable.... 
  23.  
  24.   Given that no one posting publicly mentioned the following, I
  25.   don't see how your problem could have been solved.  Personally
  26.   I'd see this as the only **sensible** solution to the task of 
  27.   entering and manhandling a 300K-odd file inside the HyperCard:
  28.  
  29. (a) read it into a variable; no limits on size but that of
  30.     available memory.
  31.  
  32. (b) process it inside that variable, not in any field
  33.  
  34. (c) store in full as a resource of type TEXT (or some other)
  35.     inside the resfork of the current or some other stack
  36.     using one of the public-domain XCMDs for that (in Developer
  37.     Stack 1.3 among others).  There are no limits on size of
  38.     resources other than the physical size available on a volume.
  39.     In this fashion you could ALSO compress the text with the
  40.     available CompressString XFCN prior to storing it, thus 
  41.     leading to great savings in archive space.
  42.  
  43.   The _standard_ answers supplied here, that of dividing the entire
  44.   text mass into a number of cd or bg fields --hidden or visible
  45.   doesn't matter much-- is hardly an optimal solution, since it
  46.   means adding a lot of complexity for management of those fields
  47.   etc.  It **may** work fine for text whose record format is known
  48.   in advance...  like, say, each line being of a max certain length,
  49.   and each particular group of lines constituting a 'record',
  50.   clearly delimited by the beginning of some next-record cookie. 
  51.   Otherwise it has all the potential of mayhem.  But perhaps you
  52.   received other replies via direct email.... 
  53.  
  54.  
  55. > 1) The read command only lets you import 16k at a time (according
  56. > to the Complete HyperTalk Handbook). 
  57.  
  58.   That limit (16384 chars) has been done away with in HC 2.1
  59.   Still, you might as well use this code:
  60.  
  61.  --make sure it<>empty first -----------------------example handler
  62.  
  63.  open file myFile
  64.  
  65.  if short version of HyperCard< 2.1 then
  66.    repeat until it=empty
  67.      read form file myFile for 16384
  68.      put it after myText
  69.    end repeat
  70.  else
  71.    repeat until it=empty
  72.      read from file myFile until eof --minimizes # of disk accesses
  73.      put it after myText
  74.    end repeat
  75.  end if
  76.  
  77.  close file myFile --------------------------end of example handler
  78.  
  79.  
  80. > 2) There is no mechanism to search backward in a file.  (ie.  you
  81. > can read until a certain character/word/whatever, but there is no
  82. > way to tell HC to "read until Mercutio then go back 100 lines and
  83. > import the next 200"
  84.  
  85.   Well, the idea is to read it ALL, all of the text into a memory
  86.   container (i.e. a variable) first, then parse/ operate on that
  87.   instead.  You can implement **ANY** type of forward/ backward
  88.   fetches, appends etc.  No need to access the disk more than
  89.   at (re)write-to time.
  90.  
  91.  
  92. > Will HC 2.5 remedy these? When will it be out, anyway?
  93.  
  94.   I don't know but expecting a newer version of any program to be
  95.   a panaceum for its current reincarnation seems to me a bit over-
  96.   ambitious. There is simply no substitute for system-analysis stage
  97.   leading to choice of adequate algorithms and data structures for
  98.   the job.  All that you've requested is quite easily solveable using
  99.   the present HC. 
  100.  
  101.  
  102. __Ian
  103.