cline@pnet01.cts.com (Ben Humphreys) (04/14/88)
In quest of a decent editor...
It seems every time I turn around, I am operating under a different editor.
It's WordStar for DOS programming, WordStar 2000 for manuals under DOS,
Lyrix for manuals under UNIX, vi for quick and dirty changes. It gets real
hard to remember all the commands. So, in hopes of standardizing all my
word processors, I began looking for something that would run under both
DOS and XENIX.
EMACS
-----
I finally got Emacs (3.9 I believe) to compile under Turbo C last night.
The only real hitch was the linking (all the file names add up to > 128
characters). Using a response file cured that problem.
When compiling with tcc -c *.c (makefile didn't work with Borland's MAKE),
I saw about 40 warning messages go by. Most (if not all) seemed trivial.
When linking, the only error message I received was:
Error: _ANSIHELLO defined in module ANSI.C is duplicated in module ANSI.C
No big deal as I was not using ANSI escape sequences anyway. The
executable ran fine.
I began changing all the defines for XENIX in estruct.h. When I went to
save the file in WordStar, it's size went from 22k to 5k (the 5k being the
last 5k of the file). Using WordStar 2000 to make the changes, the file
remained intact. Perhaps a misplaced ^Z or something. I began copying all
the source files over to my XENIX disk. cc compiled everything fine with a
few warning messages to the effect:
Warning: xx different levels of indirection
in a few source files.
cc's call to ld (I think) produced the message:
DGROUP > 64k
Well, not knowing the development system all that well, I thought adding
the switch -LARGE might help. It didn't as I recall. Then I remembered
someone suggested the switch -Ml2t128 for monster programs worked well. I
added that and got a new message from the linker after recompiling all the
source files:
Fixup overflow near 008b in segment PREPROC_TEXT in \
/lib/Llibc.a(signal.o) offset 262d8H
Has anyone been successful in producing an executable Micro EMACS under SCO
XENIX 2.1.3? I sure haven't.
JOVE
----
If I can get a decent copy of Jove, I'll give it a try. The trouble is,
I'm not familiar with "downloading?" from hipl.psych.nyu.edu.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!cline
ARPA: crash!pnet01!cline@nosc.mil
INET: cline@pnet01.CTS.COMcline@pnet01.cts.com (Ben Humphreys) (04/16/88)
The major problem I was having with both editors was not the editors
themselves, but rather my archaic 2.1.3 development system. It turns out (as
I was told by a resident sage), the 2.1.3 development system has a bug in it
(this is regarding the Fixup error). One must "ar x /lib/Llibc.a signal.o"
and link in signal.o separatly to avoid the fixup error. Knowing this, I can
probably get Jove to compile now.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!cline
ARPA: crash!pnet01!cline@nosc.mil
INET: cline@pnet01.CTS.COMdonegan@stanton.TCC.COM (Steven P. Donegan) (04/16/88)
In article <2815@crash.cts.com>, cline@pnet01.cts.com (Ben Humphreys) writes: > In quest of a decent editor... > > It seems every time I turn around, I am operating under a different editor. > > Well, not knowing the development system all that well, I thought adding > the switch -LARGE might help. It didn't as I recall. Then I remembered > someone suggested the switch -Ml2t128 for monster programs worked well. I > > Fixup overflow near 008b in segment PREPROC_TEXT in \ I was one who suggested Ml2t128 I would suggest, based on the fixup verbiage, that you should try Ml2t256. I believe that fixup is working on segmentation. I have not captured EMACS lately, if anyone has an archive of this, uucp available, I'll try my hand at this porting. It's the computer/opsys I can afford for home. (I'd love to have sufficient power available for my hobbies, but there isn't a swap meet cray compatable with unix for under 5k$ yet...:-))) -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
mdc@mcp.entity.com (Marty Connor) (04/18/88)
In article <2815@crash.cts.com>, cline@pnet01.cts.com (Ben Humphreys) writes: > In quest of a decent editor... > Warning: xx different levels of indirection > in a few source files. This is probably ok. A little caste might make it go away, but shouldn't hurt anything. > cc's call to ld (I think) produced the message: > DGROUP > 64k This means you had more than 64K in your 'small-model' data segment I think. I believe you have to compile uEmacs 3.9 as a large model program. > Well, not knowing the development system all that well, I thought adding > the switch -LARGE might help. It didn't as I recall. This lets you compile like large source files, but unless you use the flags '-Ml2e' you will not get a large model program, and it will still not link. Then I remembered > someone suggested the switch -Ml2t128 for monster programs worked well. I > added that and got a new message from the linker after recompiling all the > source files: Close, very close. The '-Ml' says large model. The '2' says make 286 instructions. The 't128' says put anything larger than 128 bytes in its own segment. probably not a good idea for this program. > Fixup overflow near 008b in segment PREPROC_TEXT in \ > /lib/Llibc.a(signal.o) offset 262d8H Yeah, I would just say "-Ml2e" or "-Mle" (the 'e' says enable keywords 'far' and 'near'). > Has anyone been successful in producing an executable Micro EMACS under SCO > XENIX 2.1.3? I sure haven't. I did once do this. I think you should be able to also. If you get 'infinite spill' errors, you should find the lines that give them and change code of the form: foo->bar[i++]; to foo->bar[i]; i++; the compiler gets confused sometimes. Bon Chance. I think if you can afford it you should upgrade to 2.2.1 or 2.2.2. I used 286s and switched to a 386 and got away from a lot of this memory model madness. The x86 architecture still is pretty brain dead in some ways though. ---------------- While I have you all here, had anybody gotten KCL to work on SCO XENIX 386 V 2.2.1? It seems to take great offense at the memory management of SCO. We want to modify code in the text section, and apparently it is not allowed. All ideas thankfully received. -- ---------------- Marty Connor Director of Innovation, The Entity mdc@mcp.entity.com, ...{harvard|uunet}!mit-eddie!spt!mcp!mdc
fox@alice.marlow.reuters.co.uk (Paul Fox) (04/22/88)
In article <2815@crash.cts.com> cline@pnet01.cts.com (Ben Humphreys) writes: >In quest of a decent editor... > >It seems every time I turn around, I am operating under a different editor. >It's WordStar for DOS programming, WordStar 2000 for manuals under DOS, >Lyrix for manuals under UNIX, vi for quick and dirty changes. It gets real >hard to remember all the commands. So, in hopes of standardizing all my >word processors, I began looking for something that would run under both >DOS and XENIX. > Well I had the same problem. Ive used Unix for years, and when I was given my own PC, I thoughjtt 'hey, what the heck -- lets make it look like Unix, even if it isnt.' This is easy - just write a c-shell interpreter. 99% done. Next problem is editor. 'vi' is pretty quirky and not as good as current technology demands. Well I had been using vi for some time under MS-DUSH. Then I heard about an editor called 'BRIEF'. This is marvellous - multiple buffers and windows; customisable macro language; color support; actually shows you what you've marked for deletion/copying, etc, etc et al. Supports compilations from within the editor, automatic loads of things. Great. I became dependant on it. Then I get me own 386 box running Xenix (Ugh :-) ). Back to vi. This wont do back to using vi again. Well, a thought occurs to me -- since I have to run MS-DUSH and Xenux at the same time, having two different editors will just confuse me. (Having one editor confuses me!!). The answer: EMACS. PROBLEM: I have uEMACS source - absolutely no documentation and no idea what EMACS is capable of. RESULT: BRIEF now runs on Unix: Sys V.2/3, Xenix, SunOS, AIX. HOW: Well, after spending 1 year tinkering with uEMACS, the code now emulates BRIEF 100%. People at work now dependant on it. Now that I've finished BRIEF under Unix (actually called GRIEF), what should I do to it ? Suggestions on a postcard in not less than 15 words ... :-)) Anyhow, GRIEF does all that full EMACS does plus and minus a bit. Shall I distribute it over the net ?? ===================== // o All opinions are my own. (O) ( ) The powers that be ... / \_____( ) o \ | /\____\__/ _/_/ _/_/ UUCP: fox@alice.marlow.reuters.co.uk
pjh@mccc.UUCP (Pete Holsberg) (04/30/88)
In article <330@alice.marlow.reuters.co.uk> fox@alice.UUCP (Paul Fox) writes:
...
...Anyhow, GRIEF does all that full EMACS does plus and minus a bit.
...
...Shall I distribute it over the net ??
...
Please do!
stu@jpusa1.UUCP (Stu Heiss) (05/02/88)
Expires:
In article <330@alice.marlow.reuters.co.uk> fox@alice.UUCP (Paul Fox) writes:
-RESULT: BRIEF now runs on Unix: Sys V.2/3, Xenix, SunOS, AIX.
-
-HOW: Well, after spending 1 year tinkering with uEMACS, the code now
-emulates BRIEF 100%. People at work now dependant on it.
-
-Now that I've finished BRIEF under Unix (actually called GRIEF), what should I
-do to it ?
-
-Shall I distribute it over the net ??
-
Yes, especially if it's really extensible. Try to arange to post through
comp.sources.unix or comp.sources.misc so that archives will be available.
--
Stu Heiss {spl1,gargoyle,ihnp4}!jpusa1!stufox@alice.marlow.reuters.co.uk (Paul Fox) (05/09/88)
In article <610@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >In article <330@alice.marlow.reuters.co.uk> fox@alice.UUCP (Paul Fox) writes: >... >...Anyhow, GRIEF does all that full EMACS does plus and minus a bit. >... >...Shall I distribute it over the net ?? >... > Please do! > OK, it will follow soon. However, before I send it out, first does anybody know out there what will happen if I try to include the standard macros which are available with BRIEF package. I would presume they are copyright; I could just send out the compiled binaries, but would that break the copyright law ? Also, I have not done any documentation for it, since the documentation is the same as that for the PC/Mush-Dog version. I am loathe at this point to document it fully, since I do not have the time. Any thoughts ?