Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!bbn!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!ejkst From: ejkst@cisunx.UUCP (Eric J. Kennedy) Newsgroups: comp.sys.amiga Subject: Re: Turbo 'c' type interface for Amiga Message-ID: <16556@cisunx.UUCP> Date: 8 Mar 89 23:30:35 GMT References: <406@corpane.UUCP> <9599@megaron.arizona.edu> Reply-To: ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) Distribution: na Organization: Univ. of Pittsburgh, Comp & Info Sys Lines: 30 In article <9599@megaron.arizona.edu> cjeffery@arizona.edu (Clinton Jeffery) writes: >From article <406@corpane.UUCP>, by sparks@corpane.UUCP (John Sparks): >> Why isn't there something like for the Amiga?... >It wouldn't be hard to write a compiler "environment" for Lattice or Aztec C in >MicroEmacs macro language, for instance. But you still wouldn't get the >compile time speeds of Turbo-C. And microemacs macro language is one of the >slowest interpreters I have ever seen (despite its silly syntax its A LOT >better than no extension language though!) . In real program development >environments, the "shell" you refer to is the job of the editor. Turbo-C's >editor is actually pretty weak. The Amiga C compilers are close to good >enough; it is a real editor that I am wishing I had. Uedit is more than capable of doing this. There have been several environments written to connect Uedit to various compilers, but none of them have been very good, or very complete. If I ever start programming seriously (like I keep promising myself ) I will definitely work on this situation. Like I said in a previous posting, it would help a *lot* if the compiler spoke ARexx. And had a sort of resident, "looping" mode, like AmigaTeX. That would address the edit-compile-link time considerably. Then the environment could be adapted to TxEd, CED, Uedit, etc. A decent environment could still be written in Uedit's internal languange, though. -- Eric Kennedy ejkst@cisunx.UUCP