Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!src.honeywell.com!milo!shankar From: shankar@SRC.Honeywell.COM (Subash Shankar) Newsgroups: comp.sys.apple2 Subject: Re: Applications: What you'd like to see Message-ID: <1991Jan17.202210.26092@src.honeywell.com> Date: 17 Jan 91 20:22:10 GMT References: <11145@ucrmath.ucr.edu> <14880@smoke.brl.mil> Sender: news@src.honeywell.com (News interface) Organization: Honeywell Systems & Research Center Lines: 32 Nntp-Posting-Host: milo.src.honeywell.com In article <14880@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >On my "to do" list is a port of the "sam" editor to the IIGS. There are >a few serious obstacles to be overcome, though: > 1. It runs as two processes, one to manage the files and one to > manage the user interface. These would have to be merged into a > single coordinated process, not an easy job. This may not be that big an obstacle. Back in the good old days, when I actually had time to program (on a //e back then), I wrote a syntax directed program ediitor which had multiple types of tasks: user interface, data structure manipulation, and the syntax stuff (for lack of a better term). At any time, more then one instance of each task could be in the queue, from which it would be fetched, processed, and various other processes would be placed in the queue. The queue also maintained dependency graph information between the different processes (e.g. display updates are immediate, while the corresponding data structure updates may be updated later - so, you need to maintain dependencies between the data structure updates and later screen views of the corresponding information). Although this needed some thought to structuring the code modules, it wasn't particularly hard to write, nor was performance unacceptably slow (the queue was a killer to write though, since it needed large amounts of cycle saving and the standard 6502 self modifying code tricks, if I recall correctly). I'm not advocating such a kludgish approach (especially since I never finished it and went on to better things before it was debugged (after finding out that 48/64K just didn't hack it for such a memory intensive implementation)), but I'm just saying that it might not be so hard to implement. --- Subash Shankar Honeywell Systems & Research Center MN65-2100 voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@src.honeywell.com srcsip!shankar