From: ianf@random.se (HyperAgent In Disguise[tm])
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Importing/accessing text files (repost)
Summary: real programmers do it with variables
Date: 23 Nov 92 07:27:47 GMT
Organization: random design -- "Opinions, cheaply"
X-Mailer: Fernmail 1.2b2f
Apparently-To: rnews@sunet.se
X-More: Cc: <ianf@random.se> to any public reply that you may post
X-Note: First validated setext browser has now been released and may be
X-This: found in sumex-aim.stanford.edu::/info-mac/app/easy-view-21.hqx


  crawford@jhunix.hcf.jhu.edu (James E Crawford) writes on (18 Nov
  92 16:40:34 GMT):

> I would like to thank everyone for their help in solving this
> problem.  Your assistance has been invaluable.... 

  Given that no one posting publicly mentioned the following, I
  don't see how your problem could have been solved.  Personally
  I'd see this as the only **sensible** solution to the task of 
  entering and manhandling a 300K-odd file inside the HyperCard:

(a) read it into a variable; no limits on size but that of
    available memory.

(b) process it inside that variable, not in any field

(c) store in full as a resource of type TEXT (or some other)
    inside the resfork of the current or some other stack
    using one of the public-domain XCMDs for that (in Developer
    Stack 1.3 among others).  There are no limits on size of
    resources other than the physical size available on a volume.
    In this fashion you could ALSO compress the text with the
    available CompressString XFCN prior to storing it, thus 
    leading to great savings in archive space.

  The _standard_ answers supplied here, that of dividing the entire
  text mass into a number of cd or bg fields --hidden or visible
  doesn't matter much-- is hardly an optimal solution, since it
  means adding a lot of complexity for management of those fields
  etc.  It **may** work fine for text whose record format is known
  in advance...  like, say, each line being of a max certain length,
  and each particular group of lines constituting a 'record',
  clearly delimited by the beginning of some next-record cookie. 
  Otherwise it has all the potential of mayhem.  But perhaps you
  received other replies via direct email.... 


> 1) The read command only lets you import 16k at a time (according
> to the Complete HyperTalk Handbook). 

  That limit (16384 chars) has been done away with in HC 2.1
  Still, you might as well use this code:

 --make sure it<>empty first -----------------------example handler

 open file myFile

 if short version of HyperCard< 2.1 then
   repeat until it=empty
     read form file myFile for 16384
     put it after myText
   end repeat
 else
   repeat until it=empty
     read from file myFile until eof --minimizes # of disk accesses
     put it after myText
   end repeat
 end if

 close file myFile --------------------------end of example handler


> 2) There is no mechanism to search backward in a file.  (ie.  you
> can read until a certain character/word/whatever, but there is no
> way to tell HC to "read until Mercutio then go back 100 lines and
> import the next 200"

  Well, the idea is to read it ALL, all of the text into a memory
  container (i.e. a variable) first, then parse/ operate on that
  instead.  You can implement **ANY** type of forward/ backward
  fetches, appends etc.  No need to access the disk more than
  at (re)write-to time.


> Will HC 2.5 remedy these? When will it be out, anyway?

  I don't know but expecting a newer version of any program to be
  a panaceum for its current reincarnation seems to me a bit over-
  ambitious. There is simply no substitute for system-analysis stage
  leading to choice of adequate algorithms and data structures for
  the job.  All that you've requested is quite easily solveable using
  the present HC. 


__Ian
Newsgroups: comp.sys.mac.hypercard