liberte@uiucdcsb.cs.uiuc.edu (12/05/86)
How does one support editing of more than 32K text blocks? It seems that others have had trouble discovering this trick, so any free advice would be appreciated by many. No example code that we have run across addresses the issue. I am forwarding this request from the author of McFace, the MacFortran extender. Mail will be summarized. Thanks Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
joel@gould9.UUCP (Joel West) (12/09/86)
Conceptually break the file up into segments, say 8k each, and
always have at most two segments in the current TextEdit record. If you
start with the beginning of the file, and scroll through it, you
might have the TERec containing
#1
#1, #2
#2, #3
etc.
Needless to say, you have to have a disk scratch file, that you copy
to the actual file as the segments are dumped.
--
Joel West MCI Mail: 282-8879
Western Software Technology, POB 2733, Vista, CA 92083
{cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel
joel%gould9.uucp@NOSC.ARPAeric@batcomputer.UUCP (12/11/86)
In article <164500006@uiucdcsb> liberte@uiucdcsb.cs.uiuc.edu writes: > >How does one support editing of more than 32K text blocks? [...] Or do anything else with chunks of data larger than 32K? I am new to Mac programming, and can't understand why I can't make an array bigger than 32K on my 1024k Mac+? Is this some kind of holdover from the days of 128K Macs or inherent in the operating system? ++Eric Fielding DARPA Internet: eric@tcgould.tn.cornell.edu
liberte@uiucdcsb.UUCP (12/11/86)
I received a few responses regarding how to edit more than 32K bytes of text. There are several alternatives, none of which appear to me to be particularly elegant - that is, make maximal use of the built-in routines. But all ideas are appreciated. Thanks for your replies. One other alternative is to read the whole file into several smaller records each of which may be edited with built-in routines. The hassle is in splitting records which get too big and editing across record boundaries. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte ------------------------- From: spry (Andy Spry) Have you seen the newest version of the Medit editor. It handles the problem of editing >32K records by breaking the file up into pages whose size can be set by the user (up to the majic 32K) at the time the file is read in. --------------- From: woody@tybalt.caltech.edu (William Edward Woody) Organization: Calfornia Institute of Technology There are a couple of ways to edit blocks of text larger than 32K. The first way is to have some way of bringing in only a small fraction of the total file, keep tract of any changes that are made, and effectively "hack" the TEdit stuff. I'm sorry about the vague terms and the poor description; I was told how to do this once, and simply rinkled up my nose in dismay. The second (and my favorite way) to allow editing blocks larger than 32K is to simply implement your own version of the TEdit functions. It's not too difficult; most text tends to be line-oriented, so one way of storing text internally is as an array of fixed-length strings (preferably 150 or 200 char/ line), and "fake" the functionality. I know: fixed length strings take up a lot of memory in the Mac. But it's a lot faster than having to calculate where the end of each line occures! ---------------- From ihnp4!bellcore!sdh@joevax Mon Dec 8 18:52:15 1986 It seems that the way you would have to do the editing is by keeping most of the block on disk. You only keep enough in memory so that immediate scrolling and paging don't get bogged down. The trick is to keep file pointers to the next line after the end of the current block in memory and the insertion point, and using simple pointer finagling, you can handle editing of files well beyond the memory capacity of the machine. In fact you can probably handle simultaneous editing of 4 or 5 such files. The obvious drawback is that you have to do huge amounts of disk access and file copying and the like. And that will slow it down without a doubt. Another alternative is to play with the heap to let you allocate a gigantic (a few hundred K) buffer for text. You read ALL your file into this buffer and then treat it as a file structure, except in RAM. This will give you speed, but a memroy limitation. Your choice. One method of implementation is to determine upon the run of your application, the amount of memory you have to play with. If its limited, use disk files, if its huge, use RAM files. That increases your code size, of course. Retief of the CDT bellcore!sdh
dgold@apple.UUCP (David Goldsmith) (12/12/86)
In article <1783@batcomputer.tn.cornell.edu> eric@batcomputer.UUCP (Eric Fielding) writes: >Or do anything else with chunks of data larger than 32K? I am new to Mac >programming, and can't understand why I can't make an array bigger than >32K on my 1024k Mac+? Is this some kind of holdover from the days of 128K Macs >or inherent in the operating system? Neither. It is a limitation of the compilers due to the fact that the 68000 only supports 16 bit offsets for its addressing modes. The Memory Manager will support any size object up to the limit of available memory. Future releases of development tools will probably remove this restriction. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY