[net.micro.atari16] Lattice C and UUDECODE

ZCSTIN05@UDCVM.BITNET (Todd Coram) (09/15/86)

Has anyone been able to compile a desk accessory program using Lattice C?
I have tried simple tests, and conversions of programs from Alcyon, but no
luck. Is there something I am missing?

Also, I have a copy of UUDECODE written in Lattice C that I got with a GEM
Kermit. THE THING JUST WON'T WORK.... I get the messages: Short File and
No End Line . (Yes the files do really have 'end' lines.) The resulting
executables that are produced simply return me back to the desktop. If anyone
can respond to this problem, or have a UUDECODE that they know works...I
would appreciate your mail.

P.S.
    Micro-Emacs is fine..But when is some brave soul with a ST and hard disk
    gonna tackle Richard Stallman's GNUEmacs? It ONLY consists of 1 Meg of
    source code in C, (not counting the xtra Lisp functions).

FISCHER-MICHAEL@YALE.ARPA (09/17/86)

>   Also, I have a copy of UUDECODE written in Lattice C that I got with a GEM
>   Kermit. THE THING JUST WON'T WORK.... I get the messages: Short File and
>   No End Line . (Yes the files do really have 'end' lines.)

For the Alcyon compiler, you have to change the calls on "fopen" that open
*binary* files to use "fopenb" instead.  Thus, 'fopen(in, "rb")' becomes
'fopenb(in, "r")', etc.  With that change, I was able to get them to work.

--Mike Fischer
  <fischer@yale.arpa>

-------

turner@imagen.UUCP (D'arc Angel) (09/17/86)

> 
> P.S.
>     Micro-Emacs is fine..But when is some brave soul with a ST and hard disk
>     gonna tackle Richard Stallman's GNUEmacs? It ONLY consists of 1 Meg of
>     source code in C, (not counting the xtra Lisp functions).

*** REPLACE THIS LINE WITH YOUR MESSAGE ***

why? with the exception of moc-lisp what does GNUemacs have, im not
being saracastic ive just never used GNUemacs and was wondering what
the advantages over uEmacs were ?
-- 
----
		It aint life that gets me down, it's gravity

Name:	James M. Turner
Mail:	Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101
        Santa Clara, CA 95052-8101
AT&T:	(408) 986-9400
UUCP:	...{decvax,ucbvax}!decwrl!imagen!turner
CompuServe: 76327,1575
GEnie     : D-ARCANGEL

Lynn%PANDA@SUMEX-AIM.ARPA (Lynn Gold) (09/20/86)

In a nutshell, GNUemacs is much more robust than uEmacs is.
In GNUemacs, you can write your own functions and rework every
command and function to your taste without modifying the actual
editor.

GNUemacs also has a wonderful C editing mode which essentially
formats your code for you, keeps track of braces and parentheses
(how many times have you had a program fail because you left out
a brace or parenthesis?), allows you to compile the program from
within the editor, and if the compile fails, will place the cursor
at the point of the first bug in your program.  (Phwew!  LOVE those
run-on sentences!)

'Nuff said?

--Lynn  :-)
-------

turner@imagen.UUCP (D'arc Angel) (09/23/86)

> 
> In a nutshell, GNUemacs is much more robust than uEmacs is.
> In GNUemacs, you can write your own functions and rework every
> command and function to your taste without modifying the actual
> editor.
> 
> GNUemacs also has a wonderful C editing mode which essentially
> formats your code for you, keeps track of braces and parentheses
> (how many times have you had a program fail because you left out
> a brace or parenthesis?), allows you to compile the program from
> within the editor, and if the compile fails, will place the cursor
> at the point of the first bug in your program.  (Phwew!  LOVE those
> run-on sentences!)
> 
> 'Nuff said?
> 
> --Lynn  :-)
> -------
ain't nuttin' there that microemacs 3.7 for the atari doesn't or
won't have when im done (adding the make capabilities is fun)
-- 
----
		It aint life that gets me down, it's gravity

Name:	James M. Turner
Mail:	Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101
        Santa Clara, CA 95052-8101
AT&T:	(408) 986-9400
UUCP:	...{decvax,ucbvax}!decwrl!imagen!turner
CompuServe: 76327,1575
GEnie     : D-ARCANGEL

pes@bath63.UUCP (Paul Smee) (10/19/86)

I've found several problems with uudecode, which are caused by
the uuencoded file being munged by 'terminal handlers' enroute to me.
The symptoms sound like some I've seen complained about, specifically
that the file appears to decode, but bombs.  On looking at the files,
I found 2 different sorts of problem.

First, spurious 'control chars' get inserted in some cases.  In fact,
these appear to always be NULs (0x0) put in as 'delay padding' by
someones term handling software.

Second, trailing spaces get stripped.

It is fairly trivial to modify uudecode to ignore all control chars
(less that ASCII space) -- and harmless, as they should not be in
a uuencoded file.  Then, pad the line out to an arbitrarily large length
using spaces (I simply tack 64 spaces on the end, in my buffer, before
decoding a line).  Appending 64 spaces is crude and inelegant, I know, but
it insures that there will be enough in all circumstances, and is a much
simpler mod than actually looking to see how many are needed -- especially
since the line may contain as yet unprocessed control chars to be thrown away.

Since making these trivial changes I've had no problems with uudecoded fils.

Hope this helps someone...