csch@tub.UUCP (03/21/87)
Hello all NETlanders listening to that newsgroup,
My friend Jochen & me have been working on the ATARI-ST & IBM-AT versions
of uEmacs38b. We've done a lot more stuff, than the orig. ones.
i.e. ALL shell-escapes (^XC, ^X!, ^X@, ^X#) now work properly (with either
Beckemeyer-C-shell & Mark-Williams-C-shell ...) and much more enhancements
took place ...
So I've been writing to the author (lawrence@duncan) to ask him how to
get these fixes (and believe me, THERE WERE LOTS OF REAL BUGS ...)
permanently involved into the uEmacs-series. He wasn't answering me till
now, so perhaps someone else in this newsgroup will help me doing this...
Kindest regards
Clemens Schrimpe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contact via:
csch@tub.uucp
from the US: ...!pyramid!tub!csch
from Europe: ...!unido!tub!csch
Bitnet: csch@db0tui6 = tub.bitnet
tel.: +49-30-393-3574
+49-30-332-4015
tlx.: (west-germany) + 186672 rdt d
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~greg@xios.XIOS.UUCP (Greg Franks) (03/30/87)
Good day all you Atari microEMACS hackers out there. Here are some
MAJOR bugs I have found in porting microEMACS to the ST. I am using
Megamax C version 1.1.
in estruct.h, add a
#define short int
after the
#define SHORT int
line. Megamax insists on calling a short a char. Once you have done
this step, edit search.c and isearch.c and change the occurances of
short int
to
int
Megamax WILL BOMB on lines like "int int c".
In search.c, remove all occurances of static. Also in search.c, there
is a
#if LATTICE
bla bla bla
#endif
#if MWC86 | ... | V7
bla bla bla
#endif
Replace the #endif #if MWC... with #else (Its around line 1156).
I'll be sending the diffs to lawrence@duncan once I get my modem set up
(again).
Happy hacking!
--
Greg Franks (613) 725-5411 "Vermont ain't flat"
{net-land}!utzoo!dciem!nrcaer!xios!greg
(Other paths will undoubtably work too - your mileage will vary)braner@batcomputer.UUCP (04/05/87)
[] (C experts hit 'j' now!) It is a general problem with porting C programs that some C programmers assume that a 'short' is 16 bits or that an 'int' is 32 bits or that a pointer fits in a 'int'. The latter at least produces a warning from your compiler (or mine, anyway...), but the first two are real problems. When porting to Megamax (16 bit ints, 8 bit shorts) I automatically convert all shorts to ints and some ints to longs. 'Some' since most are OK, and using longs will make the program large and slow. You really have to understand the program you're porting to know for sure where it's OK. I would strongly recommend using the WORD, etc macros when _you_ write C code to simplify porting later! At least, use WORD when you access OS data-structures that are 16-bits wide, and use LONG when you need more than 16 bits. - Moshe Braner PS: Anybody got docs about writing GEM metafiles from a Megamax C program?
manis@ubc-cs.UUCP (04/07/87)
In article <611@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu.UUCP (braner) writes: >(C experts hit 'j' now!) Sorry, Moshe. >I would strongly recommend using the WORD, etc macros when _you_ write >C code to simplify porting later! At least, use WORD when you access >OS data-structures that are 16-bits wide, and use LONG when you need >more than 16 bits. No!!!! The correct way to achieve portability is via typedef, e.g., typedef int lineno, column_no; typedef long bufferindex; This way, anyone porting your code changes the type definitions (in a header file), and then recompiles. The use of meaningful type names makes code clearer, and someone porting to a different system has the choice of changing the type or accepting a limitation in maximum size (which might be appropriate on a Z80 or something else on which longs are too inefficient). ----- Vincent Manis {seismo,uw-beaver}!ubc-vision!ubc-cs!manis Dept. of Computer Science manis@cs.ubc.cdn Univ. of British Columbia manis%ubc.csnet@csnet-relay.arpa Vancouver, B.C. V6T 1W5 manis@ubc.csnet (604) 228-6770 or 228-3061 "BASIC is the Computer Science equivalent of 'Scientific Creationism'."
hays@apollo.UUCP (04/08/87)
In article <611@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu.UUCP (braner) writes: >[] > >(C experts hit 'j' now!) > >It is a general problem with porting C programs that some C programmers >assume that a 'short' is 16 bits or that an 'int' is 32 bits or that a >C code to simplify porting later! At least, use WORD when you access >OS data-structures that are 16-bits wide, and use LONG when you need >more than 16 bits. > I like the following approach better as it is more discriptive: #define int32 int /* or your 32-bit integer */ #define int16 short /* or your 16-bit integer */ /* etc */ If this is put in a header file used by all of your code then you make the change once. ..... John ..... -- John D. Hays, Consultant UUCP: ...!decvax!wanginst!apollo!hays Corporate Systems Engineering ...!uw-beaver!apollo!hays Apollo Computer Inc. CIS: 72725,424 {weekly} !MY OPINIONS, not Apollo's!
john@viper.UUCP (04/08/87)
In article <273@xios.XIOS.UUCP> greg@xios.UUCP (Greg Franks) writes: > >line. Megamax insists on calling a short a char. Once you have done >this step, edit search.c and isearch.c and change the occurances of > > short int > >to > > int > >Megamax WILL BOMB on lines like "int int c". > Why make a "fix" that could actualy -Cause- portability problems? If you're going to make any changes along the lines you mentioned, it should be to change the short int statements to short which will be consistant with the new "short" portability macro you defined and will avoid changing how the system runs on other systems. Just kicking out the "short" part of the define may make the code compile correctly on -YOUR- machine, but it totaly ignores the original intent of those variables and could cause problems or larger than necessary programs on other systems or other compilers... Not real- -REAL- likely for this one case, but the substitution you suggest is, in general, a poor way to fix the poblem when a more portable method is just as easy and lends itself to other situations as well... > >I'll be sending the diffs to lawrence@duncan once I get my modem set up >(again). > Before you send in your changes, Please double check your changes with a little imagination and make sure they're not likely to cause problems for people using other compilers or other machines... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john