lauri@MITRE-BEDFORD.ARPA ("Lauri A. Szklut") (12/12/87)
I'm sending this question to this bulletin board in addition to vms-gnu-emacs because I get the impression that no one reads vms-gnu-emacs. ---------------------------------------------------------------------- I am trying to install GNU Emacs on a VAX 8700 and VAX 11/785 cluster running VMS 4.5. The problem is when I execute [.src]build.com. I get the following error message after it loads a couple of lisp files (it dies right after it loads simple.el): Invalid read syntax: "] in a vector" The only problems I encountered until this point are: 1. The aforementioned bug check when compiling LREAD.C. I used the /NOOPT qualifier to resolve that. 2. SETVBUF is undefined in module SYSDEP when I execute LINK.COM. I don't see how this would have any effect on my system, but I could be wrong. Other than that, everything proceeded as normal thus far. Has anyone else encountered this problem? Any suggestions? Thanks. Lauri Szklut ------- End of Forwarded Message
dennis@uw-warp.UUCP (Dennis Gentry) (12/16/87)
Subject: Problems with VMS GNU Emacs 18.49 on VMS; some solutions >I am trying to install GNU Emacs on a VAX 8700 and VAX 11/785 cluster >running VMS 4.5. The problem is when I execute [.src]build.com. I >get the following error message after it loads a couple of lisp files >(it dies right after it loads simple.el): > > Invalid read syntax: "] in a vector" My guess is that you copied the .ELC files, too, but they got corrupted. So when TEMACS tries to load "simple,", it finds the .ELC and tries to use that, but it's corupted. To fix this, you can delete all your .ELC files, but if you do that, I think maybe you'll need to double (or so) PURESIZE, which is #define'd in vms.h (after being initially #define'd in config.h). Also, be sure to remember which .ELC files you've deleted. Once you've got your emacs dumped, you can byte-compile all the .EL files that should be .ELC files, and then drop PURESIZE back to its original value and recompile TEMACS and redump it. >The only problems I encountered until this point are: > > 1. The aforementioned bug check when compiling LREAD.C. I > used the /NOOPT qualifier to resolve that. Yeah, that's the only way around the bug in the DEC C compiler (both version 2.1 and version 2.3-23). I suggest /debug/noopt. > 2. SETVBUF is undefined in module SYSDEP when I execute > LINK.COM. I don't see how this would have any effect on my > system, but I could be wrong. You're right, it doesn't have any effect on your system except to stop it from linking. To fix this problem, just #ifdef it out. Someone didn't realize that VMS C's stdio defines _IOFBF, just like a "newer USG system," but VMS C doesn't have a setvbuf. Just use the setbuf (found on the next line) instead. If you use "#ifndef VMS ... else ... " to fix this problem, you'll end up duplicating a line or two, but some C compilers don't know about "#if !defined(_IOFBF) && !defined(VMS)", and you won't want to break it for them. >Other than that, everything proceeded as normal thus far. Has anyone >else encountered this problem? Any suggestions? Thanks. Another problem you'll likely find is that it hangs at baud rates lower than 2400. We fixed the problem by #ifdeffing out the the special case stuff for < 2400 baud in dispnew.c. (About line 550-570). You might not encounter this problem, but we did on one system and not on another. Emacs was treating all files as if they were write-protected. We finally figured out that you need world read on rightslist.dat. Changing the protection to wo:re fixed the problem. We have a couple of otherwise identical systems, and one seemed to come with rightslist.dat as (sy:rwed,ow:rwed,gr:,wo:) and the other with (sy:rwed,ow:rwed,gr:rwed,wo:re). It was weird. If they (or anyone) wants specific chunks of code, I'd be happy to send them out. Now for my questions: Is the Free Software Foundation incorporating any of these fixes into the distribution? Like I said, I'd be happy to send them diffs or whatever. Hasn't anyone made mail sending (and reading) work under VMS GNU Emacs yet? How about dired? If this stuff hasn't already been done, I'll start working on it shortly. If you have any problems getting GNU Emacs working properly under VMS, let me know. I want to get it working correctly (and more completely). Of course, I'd rather be running GNU Emacs under any Unix (or better yet under GNU OS!) but I, like many others, am stuck with VMS. Is anyone working on porting GNU CC to the AT&T 3b2? Can anyone tell me the details of acquiring a runnable copy of GNU CC for VMS? I snarfed the regular (unix) distribution from prep, but can't even compile the preprocessor because the DEC C compiler chokes on a large-ish #define in config.h. And the Makefile is complicated enough that I'm not looking forward to doing all the compiling by hand. I read a fairly impressive blurb about the VMS version, but I've never heard anything about it since then. I can even afford to pay(!) for an official distribution tape, but when I asked at the FSF, they told me that an official tape was about a month away (two weeks for whoever wrote it to get it to them, and two weeks for them to make a tape). If anyone could tell me who the third party was, or how to get a copy, I would appreciate it. Good luck on the port, and thanks for any answers. Dennis. ------- arpa: uw-nsr!uw-warp!dennis@beaver.cs.washington.edu usenet: {ihnp4|decvax|...}uw-beaver!uw-nsr!uw-warp!dennis -- Dennis. ------- arpa: uw-nsr!uw-warp!dennis@beaver.cs.washington.edu usenet: {ihnp4|decvax|...}uw-beaver!uw-nsr!uw-warp!dennis
jr@LF-SERVER-2.BBN.COM (John Robinson) (12/18/87)
>> My guess is that you copied the .ELC files, too, but they got >> corrupted. So when TEMACS tries to load "simple,", it finds the .ELC >> and tries to use that, but it's corupted. To fix this, you can delete >> all your .ELC files, but if you do that, I think maybe you'll need to >> double (or so) PURESIZE, which is #define'd in vms.h (after being initially >> #define'd in config.h). Also, be sure to remember which .ELC files >> you've deleted. >> Once you've got your emacs dumped, you can byte-compile all the .EL >> files that should be .ELC files, and then drop PURESIZE back to its >> original value and recompile TEMACS and redump it. Instead of building the larger purified file, leave PURESIZE alone and do this (in emacs/lisp): 1. Remove the .elc files. 2. Start ../src/temacs (no switches). 3. Load loadup.el, which will load all the normaly-resident libraries from .el files. 4. Run byte-recompile-directory to get working .elc files (the byte compiler will be running interpreted, but who cares? If you think you do, run byte-compile-file on bytecomp.el, then load its .elc (maybe in a fresh temacs), then byte-recompile-directory.). (Certain of the .elc files are explicitly avoided by loadup.el (read it for details) - simply remove these when you're done if you care). 5. Go out for a cup o' java. 6. When the compile is done, exit temacs. You can now proceed to make the dumped emacs in emacs/src. /jr jr@bbn.com or jr@bbn.uucp
mike@turing.unm.edu (Michael I. Bushnell) (12/22/87)
In article <8712181501.AA03275@ucbvax.Berkeley.EDU>, jr@LF-SERVER-2 (John Robinson) writes:
~Instead of building the larger purified file, leave PURESIZE alone and
~do this (in emacs/lisp):
~
~1. Remove the .elc files.
~2. Start ../src/temacs (no switches).
~3. Load loadup.el, which will load all the normaly-resident libraries
~ from .el files.
~4. Run byte-recompile-directory to get working .elc files (the byte
~ compiler will be running interpreted, but who cares? If you think
~ you do, run byte-compile-file on bytecomp.el, then load its .elc
~ (maybe in a fresh temacs), then byte-recompile-directory.).
~ (Certain of the .elc files are explicitly avoided by loadup.el
~ (read it for details) - simply remove these when you're done if you
~ care).
~5. Go out for a cup o' java.
~6. When the compile is done, exit temacs. You can now proceed to make
~ the dumped emacs in emacs/src.
~
There is a problem with this. Byte-recompile-directory only compiles
a .el file if the .elc file exists but is out of date. A better solution
is to, instead of deleting the .elc files, do a 'touch *.el' and then
do the same thing that the instructions above indicate. Columbian
coffee is nice this time of year.
--
Michael I. Bushnell
a/k/a Bach II
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing!mike
---
All of life is a blur of Republicans and meat!
-- Zippy the Pinheadjr@LF-SERVER-2.BBN.COM (John Robinson) (12/22/87)
>> Byte-recompile-directory only compiles >> a .el file if the .elc file exists but is out of date. A better solution >> is to, instead of deleting the .elc files, do a 'touch *.el' and then >> do the same thing that the instructions above indicate. Indeed, I forgot this detail. There is also the function batch-byte-compile: Runs byte-compile-file on the files remaining on the command line. Must be used only with -batch, and kills emacs on completion. Each file will be processed even if an error occurred previously. For example, invoke "emacs -batch -f batch-byte-compile $emacs/ ~/*.el" In principle, this could be invoked in a Makefile. I don't know whether it will run under temacs, but you could use the trick of loading the loadup.el file from the command line. This function won't have the problem with nonexistant .elc files, clearly, so removing them won't nail it. Anybody want to write the Makefile for emacs/lisp? 'Twould make a nice Christmas present... /jr jr@bbn.com or jr@bbn.uucp