jdg@elmgate.UUCP (Jeff Gortatowsky) (09/03/86)
It's me again. I took the 3 part microemacs posting (uuencoded), glued the
parts together (carefully), removed all the headers and signatures, and
uudecoded here on a Sun system. Next I took Ckermit and transmitted it to
my ST using PC/IC in the kermit image mode and the unix command line :
mysystem% ckermit -i -s emacs.ttp
BOOM BOOM. Bus errors when executed. Ok. I downloaded the uuencoded
file to my amiga (using Xmodem) and uudecoded it there. I shoved it over
to the ST to execute (also using Xmodem).
BOOM BOOM. Bus error. Ok. Take the uuencoded from my Sun directly to
the ST using kermit in the non-image mode (text). Uudecode it.
BOOM BOOM. Bus error. ARRRRRRRRRGHHHHH!!!!
Now I know the files (3 of them) were not tuncated as they all had
signatures on them. None of the 3 uudecodes ever complained. Not Unix, or
the ST's (compiled under MegaMax), or the Amiga's (compiled under Manx).
Is there a point to this? Sure is. Just for the thrill of it I decided to
uudecode the cadenza.prg and the levy.ttp that were posted eons ago.
Cadenza came up with TOS error #35 (too many files open?????). And levy
just started and exited.
So I have yet to uudecode any posting for the ST, on three different
machines, and have a working program. Up till now I guess I did not care.
But me3.7 (and the recent GEMKermit) are exceptions. I want a decent
editor that supports long (>80 chars) lines. And Gemkermit would be nice.
Gemkermit has all it resources uuencoded.
Has anyone else successful uudecode anything and had it run on the ST? What
might I be screwing up? The few binaries posted for the Amiga uudecoded
fine on the Amiga and ran. The unix binaries I've decoded also run fine.
So you'd figure I could get an ST binary to run? No way!
Could someone help on this? Could the diffs for me3.7 under MegaMax be
posted or mailed to me? Thank you for your support (B & J).
--
Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company
<Kodak won't be responsible for the above comments, only those below>paone@topaz.RUTGERS.EDU (Phil Paone) (09/03/86)
I also was unable to do anything. I didn't get the TOS error 35,
but when I ran a crash utility, I saw that I had a bus error.
I catted all files together after removing the signitures. Then
I uudecoded it without error, then I used xmodem to transfer it to my
ST and VOLIA, it didn't work.
Phil Paonejimomura@lsuc.UUCP (Jim Omura) (09/04/86)
In article <5661@topaz.RUTGERS.EDU> paone@topaz.RUTGERS.EDU (Phil Paone) writes: > > I also was unable to do anything. I didn't get the TOS error 35, >but when I ran a crash utility, I saw that I had a bus error. > I catted all files together after removing the signitures. Then >I uudecoded it without error, then I used xmodem to transfer it to my >ST and VOLIA, it didn't work. > > >Phil Paone This really emphasizes the importance of posting real source code instead of Uuencoded files. Often a slightly broken source can be repaired without reposting the whole code. Uuecoded files are generally scrap when they are busted. It makes me wonder how much Net time is going to be wasted because of the bad MicroEMACS sending. If it's re-sent, how much confusion is going to result? Cheers! -- Jim O. -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
bruce@ektools.UUCP (Bruce D. Nelson ) (09/04/86)
For some odd reason, my download of uemacs 3.7 seems to work ... at least it hasn't bombed my ST (yet!). Only problem I've encountered is some error messages which fly by quite fast saying that some of the keys are unbound or undefined (the messages do fly by FAST!) when it reads the .rc file. Bruce Nelson ...rochester!kodak!ektools!bruce
ski@dciem.UUCP (Dave Eaton) (09/04/86)
In article <517@elmgate.UUCP> jdg@elmgate.UUCP (Jeff Gortatowsky) writes: >Has anyone else successful uudecode anything and had it run on the ST? What >might I be screwing up? The few binaries posted for the Amiga uudecoded >fine on the Amiga and ran. The unix binaries I've decoded also run fine. >So you'd figure I could get an ST binary to run? No way! I just finished putting together uniterm.prg, uudecoding it on an 11/70 running UNIX v7, and transferring it to my ST using Xmodem. Simon Poole was decent enough to indicate how many bytes to expect in the uudecoded version, consequently I was able to check that the uudecoded version was the correct size. When I looked at the Xmodem transferred version on the ST it was 16 bytes larger. I obtained a hex dump of the beginning and end of the uudecoded version and compared it to the version on my ST and found that there were extra characters at the end of the program. After editing these out using H&D's Tool Box, uniterm.prg worked fine. My success with program transfers has been varied. This is the first time I was able to recover from what I thought was a failed transmission. The next time it happens I will certainly check the byte totals on both machines. It was nice to have the actual byte total to check whether the posting arrived on our 11/70 successfully. I hope future postings include this feature. Dave Eaton D.C.I.E.M. Toronto, Ontario CANADA ...!ihnp4!utzoo!dciem!ski
dvadura@watdaisy.UUCP (Dennis Vadura) (09/04/86)
I have had a similar problem with uudecode/encode recently. As it turned out
I uudecoded a file on a Vax, and on the ST. But voila the file lengths were
different! This got me curious since I trust the UNIX version more than the
ST version I did some checking. As it turned out the ST version of uudecode
opened the file it was writing in ascii mode, this posed some problems with
traslation of the new-line chars. Anyway hacking the code for uudecode to
use fopenb instead of fopen and recompiling it fixed the problem!
--
--------------------------------------------------------------------------------
Dennis Vadura, Computer Science Dept., University of Waterloo
UUCP: {ihnp4|allegra|utzoo|utcsri}!watmath!watdaisy!dvadura
================================================================================FISCHER-MICHAEL@YALE.ARPA (09/05/86)
Has anyone else successful uudecode anything and had it run on the ST? What
might I be screwing up? The few binaries posted for the Amiga uudecoded
fine on the Amiga and ran. The unix binaries I've decoded also run fine.
So you'd figure I could get an ST binary to run? No way!
I have had exactly the same experience. I couldn't get the uudecoded
Cadenza files to work (TOS Error #35 just like you got), but I didn't
care much since I had no trouble recompiling the sources and getting a
working version that way. I brought GEM Kermit over from Columbia but
couldn't get the resource files decoded properly so that they could be
read into the resource construction set that came with the developers
kit. I haven't even tried to use the new uEMACS.
I too would appreciate any advice on what might be going wrong.
--Mike Fischer
<fischer@yale.arpa>
-------fxl@ADS.ARPA (Franz Lanzinger) (09/05/86)
I have successfully uudecoded ue 3.7 and kermitted it to my ST. It appears to work on my mono screen, though it appears to be set up for 43 lines (EGA PC screen) so you need the little HI50 program to get it to work. I used image mode on both ends of kermit. I used the kermit that came with the developers kit when I bought it about a year ago. I got problems when I forgot to use image mode on the ST side. Previous postings, such as the xmdm program also worked for me. I haven't tried cadenza yet. Maybe the problem lies with GEM Kermit, but this is only speculation. Franz Lanzinger Advanced Decision Systems 201 San Antonio Circle #286 Mountain View CA 94040 (415) 941-3912 fxl@ads.arpa
fischer@YALE.ARPA (Michael Fischer) (09/08/86)
Thanks to Dennis Vadura for pointing me in the right direction on my uudecode problem. I looked in the C sources for uudecode that I had received from Columbia as part of the new GEM Kermit distribution. Sure enough, it opened the binary output using fopen(<name>, "wb") . In Alcyon C, this must be replaced by a call on a different function: fopenb(<name>, "w"). Similar changes must be made to uuencode so that its binary input is opened properly. (Of course, one must also remember to declare the new function.) After making the changes, I had no trouble in decoding the Kermit resource and executable file, and they work fine. I'm looking forward now to decoding uEMACS 3.7 and other goodies that have been accumulating on the net. --Mike Fischer fischer@yale.arpa -------
mj@myrias.UUCP (Michal Jaegermann) (09/08/86)
Most of binaries I undecoded from net postings work on my ST. Even
'cadenza' :-). Some of them I even managed to decode on VAX and
transfer as image files to ST. This depends on a phase of the moon and
good humour of 'kermit' programs on BOTH ends.
Not so good luck with emacs3.7. I checked uudecoded files on VAX and
ST. They are exactly of the same length. Neverthless the program bombs
out with "#4 - Illegal instrunction trap". Is it cuased by a fact that
I tried to run it on a color monitor?
Michal Jaegermann
...ihnp4!alberta!myrias!mjwayne@batcomputer.TN.CORNELL.EDU (wayne smith) (09/09/86)
I have also successfully uudecoded ue 3.7 and kermitted it to my ST. I used GEM Kermit (which I uudecoded and kermitted with the kermit that came with the developers kit). So far, I haven't experienced problems with uudecode or kermit (or kermit at 1200 baud over an Avatex modem for that matter). Just make sure and use image mode on both ends. > It appears to work on my mono screen, though it appears to be > set up for 43 lines (EGA PC screen) so you need the little HI50 > program to get it to work. What is this HI50 program that solves the 43 line problem? At the moment, I make ue work by opening another window whose length can be adjusted to a physically realizable dimension. I seem to have a problem with the numbered macros (in the emacs.rc that came with ue). The keys are bound, but when I push them, they can't find the macro. The "help" macro works when I type ":help". It also seem that lines in the resulting text files are delimited with only a line feed (instead of line feed/carriage return) which shows up when I double click a test file and "show" it. Does the original do this, or was something lost in the translation? Nonetheless, this is an incredible improvement over the editor that came with Lattice C. Thanks, Wayne Smith Sibley School of Mechanical Engineering Cornell University Ithaca, NY
wolenty@inuxj.UUCP (R Wolenty) (09/09/86)
Finally!!!!!! I GOT A UUDECODED PROGRAM TO WORK! I was trying to get Simon Poole's UNITERM to work and kept getting TOS ERROR #35 as others have noted. When I catted the three files together I did not check the end of each unsharred file. It turns out each file had two blank lines at the end. I deleted these lines and voila it works - I'm using the VT100 emulator even now. Ron Wolenty AT&T Information Systems Indianapolis, IN
sansom@trwrb.UUCP (Richard Sansom) (09/11/86)
In article <267@myrias.UUCP> mj@myrias.UUCP (Michal Jaegermann) writes: >Most of binaries I undecoded from net postings work on my ST. Even >'cadenza' :-). Some of them I even managed to decode on VAX and >transfer as image files to ST. This depends on a phase of the moon and >good humour of 'kermit' programs on BOTH ends. >Not so good luck with emacs3.7. I checked uudecoded files on VAX and >ST. They are exactly of the same length. Neverthless the program bombs >out with "#4 - Illegal instrunction trap". Is it cuased by a fact that >I tried to run it on a color monitor? Until I ported uuencode/uudecode (about a month ago), every uuencoded program I got from the net was successfully downloaded to my ST in 8-bit "image" mode after having been decoded on our VAX (old) or Pyramid (new). People having problems with uuencoded files can probably blame non-UN*X sites for munging the files somewhere along the way. As far as blaming your color monitor for trashing uE3.7, you can forget it - I've been using it with both monochrome and color monitors for several weeks now. By the way, the color version looks great! My only complaint about uE3.7 is the SSLLOOWW disk access time (blame it on "gemdog" ;-). -- __________ ______ ____ _____ ___ /_________//___ ||__|/____|/__/ Richard E. Sansom ___ ____/ / ____________ TRW Electronics & Defense Sector / / / /\ < | /| / One Space Park Drive, R3/1028 / / / / \ \ | / | / Redondo Beach, CA 90278 /__/ /__/ \__\|__/ |__/ {...decvax,ucbvax,ihnp4}!trwrb!sansom
turner@imagen.UUCP (D'arc Angel) (09/17/86)
> monitors for several weeks now. By the way, the color version looks great! > My only complaint about uE3.7 is the SSLLOOWW disk access time (blame it > on "gemdog" ;-). > > > > > > -- > __________ ______ ____ _____ ___ > /_________//___ ||__|/____|/__/ Richard E. Sansom > ___ ____/ / ____________ TRW Electronics & Defense Sector > / / / /\ < | /| / One Space Park Drive, R3/1028 > / / / / \ \ | / | / Redondo Beach, CA 90278 > /__/ /__/ \__\|__/ |__/ {...decvax,ucbvax,ihnp4}!trwrb!sansom *** REPLACE THIS LINE WITH YOUR MESSAGE *** The problem is further complicated by the need to keep file i/o as genereic as possible so that it works on the max number of systems and that tends to limit you to getc, putc, scanf, printf etc. yeeechhh!!!! i tried buffering the i/o manually but the speed advantage gained is lost in the access time for the floppy so all the fancy (read hacked) code came out a wash. sorry -- ---- 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