mludwig@lehi3b15.UUCP (Mitchell Ludwig ) (12/10/88)
Ok, here we go... I am attempting to make 18.52 (gnu) work on my Microport 386. The machine is running Microport UN*X ver 3. Internally I've got 2 meg of usable memory. When I compile the darn thing, everything goes just grand until the makefile tries to execute ld temacs (and a whole lot of .o files...). Partway through the execution of this command I get an error concerning the system's inability to add the symbol Lisp_Subr to the symbol table and then I get gonged. I'm using the m-intel386.h and the s-usg-5-3.h in my config.h. My question is, HELP! How come? I have a friend using the freakin thing in SCO's Xenix (if this is a plug for XENIX, sorry :-) and he had none of the problems I'm having. In fact, it was the ease with which he compiled the thing which led me to give it a shot. So, does anyone 1) Have any idea why it gongs me here and with that error? 2) Have Gnu running on Microport? and 3) know of either an m or s file for my config which is more compatable with Microport. Also, if I'm gonna need to re-map my keyboard, has anyone done it yet? Any help is appreciated... You can reply to me here or directly to : UUCP : ...!lehi3b15!rastro!mfl or ...!lehi3b15!mludwig or for you internet and bitnet dudes Internet : KMFLUDW@vax1.cc.lehigh.edu Bitnet : MFL1@lehigh.bitnet Mitch
james@bigtex.cactus.org (James Van Artsdalen) (12/11/88)
In <429@lehi3b15.UUCP>, mludwig@lehi3b15.UUCP (Mitchell Ludwig ) wrote:
> So, does anyone [...] Have Gnu running on Microport?
GNU emacs 18.52 works fine under uPort unix, at least my 2.2 version.
I'll send Mitchell (and anyone else) my config.h, .emacs, and a
program I wrote to re-map the AT keyboard to something more useful for
emacs and ksh.
--
James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die"
Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759brian@cbw1.UUCP (Brian Cuthie) (12/12/88)
In article <429@lehi3b15.UUCP> mludwig@lehi3b15.UUCP (Mitchell Ludwig ) writes: > >Ok, here we go... > >I am attempting to make 18.52 (gnu) work on my Microport 386. The machine >is running Microport UN*X ver 3. Internally I've got 2 meg of usable memory. >When I compile the darn thing, everything goes just grand until the makefile >tries to execute ld temacs (and a whole lot of .o files...). Partway >through the execution of this command I get an error concerning the system's >inability to add the symbol Lisp_Subr to the symbol table and then I get >gonged. I'm using the m-intel386.h and the s-usg-5-3.h in my config.h. >My question is, HELP! How come? I have a friend using the freakin thing in [stuff deleted] Check the amount of disk space you have in the root partition. I ran into this problem on a client's system while trying to build a new kernel. After scratching my head for a few minutes I realized that all the disk space in the root partition (/) was gone. I then found out that when I had asked them to restore from the backup tape a few weeks ago, they had somehow not mounted the /usr file system. I don't know why, but the ld(er) is not very good about error messages when it runs out of disk space. This is *so* like many unix utilities. I like unix and have been using it for a *long* time, but I can't help but wonder what universe some of the people who write these utilities live in. I mean would it be so difficult to say "ld: out of /tmp space ?" I can't help but think that the major obstacle to UNIX becoming accepted in the business community has been the piss poor way in which programs die. Most of the time the program knows why it can't proceed but it just gives one of those famous "name: cryptic dribble" messages. Some utilities are definitely better than others but AT&T needs to impliment some internal standard for the way a program dies. All programs should be required to give you meaningfull error messages. Then perhaps, non UNIX people will begin to overcome their fears of using it. -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (12/12/88)
brian@cbw1.UUCP (Brian Cuthie) writes: >Partway >through the execution of this command I get an error concerning >the system's inability to add the symbol Lisp_Subr to the symbol >table Check the amount of disk space you have in the root partition. If this is in fact the problem, then try setting the environment variable TMPDIR to some directory on a filesystem with lots of excess space. All the SysV standard utilities will write their temp files there rather than in /tmp. --Karl
debra@alice.UUCP (Paul De Bra) (12/12/88)
In article <121@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >... >I don't know why, but the ld(er) is not very good about error messages when >it runs out of disk space. This is *so* like many unix utilities. I like >unix and have been using it for a *long* time, but I can't help but wonder >what universe some of the people who write these utilities live in. I mean >would it be so difficult to say "ld: out of /tmp space ?" >... What's wrong with the message the kernel should display on the console: /tmp: file system full and which it repeats for every attempted write? I don't know about Microport but every other unix system I have worked on will give you this message. I think it's a neat idea to put this message in just one place (in the kernel) rather than to repeat it in every utility. And though it used to be a problem on multiuser systems where you might not notice the messages on the console (though the system surely came to a crawl which everyone should notice) on these mighty PC's where one always uses the console this should be even more acceptable than before. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
jxw@RODS.IUS.CS.CMU.EDU (John Willis) (12/13/88)
Several weeks ago I was able to compile GNU-Emacs 18.52 under Microport 3.0 and /bin/cc. You need to be careful because the LISP files default to loading a compiled version (.elc) rather than a pure ASCII source version (.el). Somewhere along the transmission path, if you assume that the source is all ASCII, these compiled files will probably be corrupted. There is a simple fix, as documented by Stallman in the release notes. 1) Increase the amount of memory allocated to pure lisp (I think the define is at the end of config.h). 2) Recompile (only alloc.o is probably sufficient, check). 3) Delete all of the .elc files from the LISP directory. 4) Load the new temacs, defaulting to .el representations. 5) Recompile .el files into .elc files (something like byte-compile-directory ../Lisp) 6) Reduce the pure lisp storage (reversing (1) above). 7) Rebuild emacs, loading the .elc files by default. Like the other GNU tools, this is an excellent editor. It's worth a little effort. If this doesn't get you a running Emacs 18.52, I'll try to help. -John --
" Maynard) (12/13/88)
In article <8525@alice.UUCP> debra@alice.UUCP () writes, in reference to a kernel message written to the console: >And though it used to be a problem on multiuser systems where you might >not notice the messages on the console (though the system surely came to a >crawl which everyone should notice) on these mighty PC's where one always >uses the console this should be even more acceptable than before. Hate to tell you this, Paul, but I'm on /dev/cons1 right now on my AT-clone, not /dev/console. I hardly ever flip over to /dev/console; insted, it's reserved for those times that I need to log on as root to get something done. Next suggestion? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!tness1! | Eight more years! Eight more years!
debra@alice.UUCP (Paul De Bra) (12/13/88)
In article <778@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: ]In article <8525@alice.UUCP> debra@alice.UUCP () writes, in reference to ]a kernel message written to the console: ]>And though it used to be a problem on multiuser systems where you might ]>not notice the messages on the console (though the system surely came to a ]>crawl which everyone should notice) on these mighty PC's where one always ]>uses the console this should be even more acceptable than before. ] ]Hate to tell you this, Paul, but I'm on /dev/cons1 right now on my ]AT-clone, not /dev/console. I hardly ever flip over to /dev/console; ]insted, it's reserved for those times that I need to log on as root to ]get something done. Next suggestion? ] I hate to tell you this, Jay, but Microbug clearly blew it on this one again. With SCO Xenix you would get the messages no matter on which virtual console you are. So you can figure out my next suggestion... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
brian@cbw1.UUCP (Brian Cuthie) (12/14/88)
In article <8525@alice.UUCP> debra@alice.UUCP () writes: >In article <121@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >>... >>I don't know why, but the ld(er) is not very good about error messages when >>it runs out of disk space. This is *so* like many unix utilities. I like >>unix and have been using it for a *long* time, but I can't help but wonder >>what universe some of the people who write these utilities live in. I mean >>would it be so difficult to say "ld: out of /tmp space ?" >>... >What's wrong with the message the kernel should display on the console: >/tmp: file system full >and which it repeats for every attempted write? > Well, actually, it doesn't do that for microport Sys V/386. Plus, I'm not sure that it's reasonable for user A to have to wonder what's wrong with his program when the messages are bombarding user B. Seems kind of stupid to me. I will stick with my original statement: ALL PROGRAMS SHOULD SAY *IN CLEAR ENGLISH* WHY THEY DIED ! I mean, GEEZ, what is it that makes people want to keep unix messages cryptic. Could it be job security ?? I sure don't know. -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu
mludwig@lehi3b15.UUCP (Mitchell Ludwig ) (12/14/88)
In article <11544@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >GNU emacs 18.52 works fine under uPort unix, at least my 2.2 version. >I'll send Mitchell (and anyone else) my config.h, .emacs, and a >program I wrote to re-map the AT keyboard to something more useful for >emacs and ksh. James, thanks alot for your help. Believe me it made life alot easier. The remap is real nice. But (there is *ALWAYS* a but), I am now having a new problem. I'm now a happy user of GNU 18.52, well, almost happy. RMAIL hates me. My system is hooked via uucp to an internet gateway of sorts. It's also hooked to another independent machine. I can't talk to either of them. I can originate messages to either, but responding aint a happy time. The 3b15 (which is my internet host) mails to me with the extension of @lehi3b15.UUCP which my mailer hates. I guess it's the @ sign. Any help there? And with ubu, the indep. machine, all mail from him seems to be coming from my uucp account, and rmail replies to it there. So I'm in deep kaka and sinking fast into the mud. Any help is appreciated... Mitch ...!lehi3b15!mludwig ...!lehi3b15!rastro!mfl (but don't expect a reply :-)
guy@auspex.UUCP (Guy Harris) (12/14/88)
>And though it used to be a problem on multiuser systems where you might >not notice the messages on the console (though the system surely came to a >crawl which everyone should notice) on these mighty PC's where one always >uses the console this should be even more acceptable than before. It's arguably still a problem on those multiuser systems; they haven't gone away. Furthermore, programs should print them *anyway*; programs should check for I/O errors and report them. They should also "do the right thing" when they occur; for instance, an SMTP daemon should *not* acknowledge receipt of mail until it has written the mail out with no errors *and*, if at all possible, has ensured that the data has actually been written to non-volatile storage (using "fsync" on systems that have it, otherwise using O_SYNC mode when writing on systems that have it). As long as you're checking for errors such as this, it's not that much harder to print a message as well.... Furthermore, it's not always obvious what *caused* the file system to fill up; it might have been caused by a daemon program as opposed to a command the user ran (or it might have been caused by a background job the user started, or by somebody who remotely logged into your machine running a job, or...). A message from the program, giving the source of the message (e.g., "ld", or maybe even better "cc"), would do that better than just "/tmp: file system full".
lars@myab.se (Lars Pensj|) (12/14/88)
In article <8525@alice.UUCP> debra@alice.UUCP () writes: >In article <121@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >>... >>I don't know why, but the ld(er) is not very good about error messages when >>it runs out of disk space. This is *so* like many unix utilities. I like >>unix and have been using it for a *long* time, but I can't help but wonder >>what universe some of the people who write these utilities live in. I mean >>would it be so difficult to say "ld: out of /tmp space ?" >>... >What's wrong with the message the kernel should display on the console: >/tmp: file system full > >I don't know about Microport but every other unix system I have worked on >will give you this message. I think it's a neat idea to put this message in >just one place (in the kernel) rather than to repeat it in every utility. I strongly disagree here. It is of vital importance that all programs on their own check results of system calls (like write). Even if some people uses the console, there are always a lot of people who do not. It is also important that a program wich fails on a system call (as in this case) immediately terminates (if it does not know how to recover). I have had to much contact with programs that take for granted success of some functions, with the result that the programs just fails without telling why. Especially when porting to new systems. And when a system call fails, always use perror. -- Lars Pensj| lars@myab.se
mdt@s1.sys.uea.ac.uk (M.D. Templeton GEC ) (12/16/88)
o Item 1
I have emacs v 18.45, on a Sun 3/50 and have a teeny weeny problem.
If I use the mouse in suntools, say with two emacs windows displayed,
to select an emacs menu option, say to expand the current window,
the message I get is:
Invalid function: (macro lambda (window &rest forms) "Switch to WINDOW, evaluate FORMS, return to original window." (byte-code .....
The dots were my idea!
The function does seem to be performed, though. I also can't get any effect
from the middle mouse-key.
Any ideas, fixes, patches????
o Item 2:
Does anyone in the UK or Europe have a copy of emacs 18.52, and the will
to put it on a tape for me (I'll supply the tape of course).
Similarly, anyone over here got the other FSF programs, and/or a
system for getting updates/new versions as they come available??
o Thanks in advance for help with both of these items.
Mark D Templeton (The Druid)
Janet: mdt@uk.ac.uea.cs
Voice: 0603-56161 x 2308 (UEA)
0634-44433 x 60 (GEC)
0634-364150 (home - 18-Dec-88 to 3-Jan-89)jr@bbn.com (John Robinson) (12/16/88)
In article <291@s1.sys.uea.ac.uk>, mdt@s1 (M.D. Templeton GEC ) writes: >o Item 1 > I have emacs v 18.45, on a Sun 3/50 and have a teeny weeny problem. > If I use the mouse in suntools, say with two emacs windows displayed, > to select an emacs menu option, say to expand the current window, > the message I get is: > >Invalid function: (macro lambda (window &rest forms) "Switch to WINDOW, evaluate FORMS, return to original window." (byte-code ..... This is one of those problems that crop up from time to time. What happened is that one of the sun-*.el files was byte-copmiled without the proper macro definitions having been made first. Though I have 18.52, it appears that the macro in question is eval-in-window, which is used in sun-fns.el and sun-mouse.el, and defined at thge top of the latter. The error you got is that the macro definition was called as a function, which doesn't work. The fix is to load the file defining the macro before byte-compiling files that use the macro. In your case, connect to the emacs/lisp directory and do the sequence: (load-file "sun-mouse.el") (byte-compile-file "sun-mouse.el") (byte-compile-file "sun-fns.el") or the equivalent interactive calls. Check first that the defmacro in question is in sun-mouse.el, as 18.45 may differ from 18.52. To be safe, you may want to load-file on all the sun-*.el files and byte-compile them all. Do all the load-files first. -- /jr jr@bbn.com or bbn!jr
mdt@s1.sys.uea.ac.uk (M.D. Templeton GEC ) (12/16/88)
Another one.. Emacs has a terminal emulator. As I need a vt100 terminal emulator for a Sun 3/60, I thought this a good idea. However, the emacs terminal emulator seems to emulate some unknown terminal type. Does anyone have the lisp to make a VT100 version?? Alternatively, any suggestions as to how I can get vt100 emulation through suntools, or anything else?? ps. Although I have emacs 18.45, I only have the manual/info files for version 17. Mark D Templeton (The Druid)
debra@alice.UUCP (Paul De Bra) (12/17/88)
In article <448@myab.se> lars@myab.UUCP (Lars Pensj|) writes: >... >It is of vital importance that all programs >on their own check results of system calls (like write). >... I agree, but unfortunately very few programs actually do this for read and write. It is very common in Unix utilities to check the result of the open system call and then just assume that writing and closing will go well. Reasons are obvious: programmers are a bit lazy, and the programs become smaller and faster if you don't check. (so not checking also makes your system look better in benchmarks which use standard utilities...) The administrative advice which is given with every Unix system (or at least used to be given) is that the system administrator should regularly check the amount of free space on all file systems, to make sure they never get full. This administrative procedure may no longer be considered acceptable, but remember that lots of utilities have not changed, so they still rely on this assumption. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
plocher@uport.UUCP (John Plocher) (12/17/88)
In article <8530@alice.UUCP> debra@alice.UUCP () writes: >I hate to tell you this, Jay, but Microbug clearly blew it on this one >again. With SCO Xenix you would get the messages no matter on which virtual >console you are. So you can figure out my next suggestion... > >Paul. The messages printed by Unix kernels use a version of printf() which bypasses the complete Virtual Console Subsystem and dumps the text directly to the screen. This is done by the ATT, ISC, Microport, and SCO versions of Unix to make sure the messages get seen (what would happen if there was a bug in the console driver and you couldn't change to the console VC? You'd still want to see the message! These messages also pass thru the osm (Operating System Messages) driver so you can log them to a file amd find them with crash(1M). -John Plocher
chip@ateng.ateng.com (Chip Salzenberg) (12/22/88)
In article <448@myab.se> lars@myab.UUCP (Lars Pensj|) reminds us that all programs should check return values of system calls, such as write(). This is obviously good policy. However, according to debra@alice.UUCP (Paul De Bra): >... unfortunately very few programs actually do this for read and write... >Reasons are obvious: programmers are a bit lazy, and the programs become >smaller and faster if you don't check. (so not checking also makes your >system look better in benchmarks which use standard utilities...) This misconception about "efficiency" is all too common. Checking the return values of system calls takes some programmer time during coding, but this is more than returned during debugging and use. ("A bit lazy"? Try "lazy enough to get fired".) And as for execution speed: how long does an integer comparison take? Certainly not enough to worry about, once you've accepted the overhead of a kernel trap. And this fellow works in AT&T Research. Sigh. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."