November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Ben Wing

Many of you may have noticed that I have been effectively absent for the last month or so. This note merely makes it official. I have unsubscribed from all of the XEmacs lists, and I'm going to be out of the country for a few months studying Portuguese in Brazil. I probably won't be reading my email during this time, so if you want to say something to me, do it in the next week and a half. I'm not sure whether I'm going to be coming back to XEmacs once I return next March. At this point I'm a little frustated with trying to work on a project where I can't actually do anything myself because of my physical problems. -- Ben Wing (typed by Martin)

1 participants
0 comments

Re: Spurious "file has changed on disk" warnings on Linux 27 years

Darron Shaffer

Justin Vallon <vallon(a)mindspring.com> writes: > On 7 Nov 1998, SL Baur wrote: > > > Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org: > > > > > I seem to remember somewhere that NFS writes may be postponed until > > > close(). > > > > This brings back bad memories of old flame wars. I don't think NFS > > will do this, but I know AFS can raise errors on close. If Dejanews > > has restored enough old netnews, there should be megabytes on this > > topic in the old archives. > > (snip) > > HP/UX 10.20, man close: > > ERRORS > close() fails if the any of following conditions are encountered: > > ... > > [ENOSPC] Not enough space on the file system. This error > can occur when closing a file on an NFS file > system. [When a write() system call is executed > on a local file system and if a new buffer needs > to be allocated to hold the data, the buffer is > mapped onto the disk at that time. A full disk is > detected at this time and write() returns an > error. When the write() system call is executed > on an NFS file system, the new buffer is allocated > without communicating with the NFS server to see > if there is space for the buffer (to improve NFS > performance). It is only when the buffer is > written to the server (at file close or the buffer > is full) that the disk-full condition is > detected.] > > So, it appears that at least the HP NFS write() call can be cached and the > cache is not write-through. Hence, a flush would most likely be required, > or else stat() may be using a stale last-modify time. The NFS server on VOS used to do something worse. After the close, the modtime of the file would change slowly for about 20 seconds, then settle to a stable value. My solution was to edit using ange-ftp instead of NFS, as it was not only more reliable but also faster. The VOS NFS server was a piece of junk. It may still be, but I haven't had occasion to use it for about 3 years. Darron Shaffer

1 participants
0 comments

Re: Spurious "file has changed on disk" warnings on Linux 27 years

SL Baur

Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org: > On Fri, 6 Nov 1998, Kyle Jones wrote: >> > > Fix #2: Change order of close and stat >> > >> > This would seem to be the correct solution. On other systems it should >> > not make any difference. The only thing is, why wasn't it done before? >> >> stat() is relatively expensive compared to fstat(). Also, it >> is surprising (to me) that close() would fiddle with the file >> modtime, given that close() does no implicit flushing of data. > I seem to remember somewhere that NFS writes may be postponed until > close(). This brings back bad memories of old flame wars. I don't think NFS will do this, but I know AFS can raise errors on close. If Dejanews has restored enough old netnews, there should be megabytes on this topic in the old archives. > That is, close() may give errors such as disk full, etc, because > for performance reasons, write() is only done locally and disk allocation > is not done until close [or a later write]. Something like that, as I recall.

3 participants
2 comments

Re: Spurious "file has changed on disk" warnings on Linux 27 years

Hrvoje Niksic

Charles G Waldman <cgw(a)pgt.com> writes: > On a more general note, why is HAVE_FSYNC being handled the way it > is (in src/sysfile.h) instead of by the configure script? The > existing logic seems convoluted - since Linux #defines USG, sysfile > decides not to #define HAVE_FSYNC, even though Linux has fsync. Am > I misunderstanding the purpose/meaning of the HAVE_FSYNC symbol? > What does USG have to do with it? Only Martin is truly competent to answer this, but if I had to guess, I'd say it's a remnant of the pre-configure period, when all the HAVE_* symbols were handles by s/m files. If we want to use HAVE_FSYNC, we should simply check it via Autoconf. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Predestination was doomed from the start.

2 participants
1 comments

Re: Spurious "file has changed on disk" warnings on Linux 27 years

Jan Vroonhof

Charles G Waldman <cgw(a)pgt.com> writes: > Changing src/sysfile to read > #if defined (LINUX) || !defined (USG) && !defined(WINDOWSNT) > > causes the fsync to be done, and makes the problem go away. Since there is no real need to do the fsync since this seems the wrong solution. Also it is a platform-specific decision. > Fix #2: Change order of close and stat This would seem to be the correct solution. On other systems it should not make any difference. The only thing is, why wasn't it done before? Jan

4 participants
4 comments

Re: Concatenating of directory strings 27 years

Michael Sperber

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> At 12:14 06/11/98 +0100, Michael Sperber [Mr. Preprocessor] wrote: >> Yeah, why don't you keep me involved in this discussion infinitely. >> This way, I'll never get around to looking at it. This is seriously >> starting to annoy me. Andy> C'mon Michael. There is a patch, with a ChangeLog and explanation that I Andy> have seen many times before. Sure, and I'm grateful for it. Andy> If you don't apply it, people will apply it Andy> anyway and you will still get FAQ's. If you don't apply it we (you Andy> especially) will get far more FAQ's from people wondering why efs doesn't Andy> work. I'm willing to take that risk based on my past experience. Andy> I really don't see what the big deal is. This has been simmering for Andy> *months*, is it really that hard to expedite this one patch? Given my current situation, yes. I need to keep the EFS XEmacs package synchronized with the official releases, otherwise I'll go nuts. So it's (on top of the technical complications which I haven't fathomed yet) significantly more effort than just applying a patch to the repository. Please accept that I've heard your arguments, I know it should be done as soon as possible, and I'll do it as soon as I can. Stop badgering me. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Xemacs for Windows 27 years

Rob Bishop

Hi Folks, Someone told me that you might be able to help me with my xemacs woes. I really love using xemacs on my Solaris machine, but my work environment has changed to Windows 98. I found xemacs for Windows, but it behaves differently in some unfortunate ways. The worst way is that I can't seem to control the color of text. My old xemacs-options file doesn't seem to have any effect. And when I went into the customization feature of xemacsPC, I tried to set the background for text to be blue. But that gave me a blue background only where text was present. So the empty spots (such as blank lines) in my source code are all white. And I can't figure out how to turn the empty spots blue. Can anyone there help me, or point me in the right place to look for help? Thanks. Rob -- Genetics explains why you look like your father and if you don't why you should. Rob Bishop, LSI Logic | rbishop(a)lsil.com | (408) 433-2846

2 participants
1 comments

Re: wierd color problem with xemacs-21.0-b57 27 years

Jan Vroonhof

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > The tags are now light blue in the X11 frame, and underlined in the > tty frame. Just as the defface for `custom-face-tag-face' specifies > them to be. Note that that is not a good test. The X11 specification also includes an underline so you cannot see the difference (unless your xterms can show color f course). The way to reproduce is (with XEmacs 21.0) xemacs -vanilla & M-x customize RET M-x customize-face RET custom-group-tag-face RET Change the X specs to not have underline and set. -> This change is made in the X frame M-x gnuserv-start RET In a 'non-color' xterm gnuclient -nw -> The customize buffer has underline Group tags C-x 5 b RET 'creates new tty frame' C-x b *Customize Group: Emacs* RET -> The group tags are NOW not underlined! It seems as thought custom stuff to make the faces for the new tty frame are not called. However under XEmacs 20.4 this does indeed work!

2 participants
1 comments

vfork revisited (was 64bit clean XEmacs) 27 years

Georg Nikodym

The discussion about XEmacs blowing with really large mail messages reminded me of a concern that I had a long time ago about *macs and subprocesses. When a UNIX process wants to create a child, it fork()s and exec()s. The fork() duplicates the parent's address space. This was seen as silly when 9 times out of 10 the child simply calls exec and thus was born vfork(). vfork() has this problem, though that the child briefly runs in the parents address space. The implications of this statement are serious and have resulted in two things. First, standards authors have had no choice but to say that you can't guarantee anything aside from exec() or _exit() will work. Second, application developers have been bitten by all kinds of nasty bugs and have shied away from vfork. The net result is that vfork() could probably be removed from the UNIX ABI and nobody would shed a tear. However, some processes get ridiculously large. Fork/exec on a >100MB process can be quite silly... and knowing that there have been some important bug fixes within Solaris' vfork I decided it was time to have a second look. I hacked process-unix.c to use vfork() instead of fork(), built, and ran. I then loaded up a whole bunch of large files I have kicking around until I ran out of memory (for those really curious, there's pmap output at the bottom of this mail). I then started using things like M-x shell to create subprocesses. I kept going until I exhausted the per process file descriptor limit. Were my XEmacs using fork(), those shells would never have gotten started because the calls to fork() would fail. So, for those folks playing with 36MB mail attachments for which mmencode needs to be called as a subprocess, seems like vfork might not be so bad after all... Rather than shun vfork, perhaps careful examination and rationalization of all the code that gets run in the child after the [v]fork() would be a plan... Of course, the right answer is for UNIX at large to adopt the Plan 9 rfork()... Comments? P.S. I'm going to run with vfork() instead of fork() for a little while to see if I run into any nasties that weren't uncovered by my experiment. I'll keep you posted. ----------- pmap output: 3174: src/xemacs Address Kbytes Resident Shared Private Permissions Mapped File 00010000 5280 4208 - 4208 read/exec xemacs 00546000 2408 2160 - 2160 read/write/exec xemacs 007A0000 30640 9264 - 9264 read/write/exec [ heap ] D5C00000 5584 5448 - 5448 read/write [ anon ] D6400000 10152 9688 - 9688 read/write [ anon ] D7400000 4936 4888 - 4888 read/write [ anon ] D7C00000 16344 12696 - 12696 read/write [ anon ] D9400000 10152 7904 - 7904 read/write [ anon ] DA400000 7096 6504 - 6504 read/write [ anon ] DAC00000 11448 8480 - 8480 read/write [ anon ] DBC00000 7992 7016 - 7016 read/write [ anon ] DC400000 11448 7952 - 7952 read/write [ anon ] DD400000 6304 4912 - 4912 read/write [ anon ] DDC00000 5584 3752 - 3752 read/write [ anon ] DE400000 4936 3952 - 3952 read/write [ anon ] DEC00000 4936 3160 - 3160 read/write [ anon ] DF400000 11448 6560 - 6560 read/write [ anon ] E0800000 6304 4104 - 4104 read/write [ anon ] E1000000 4936 2912 - 2912 read/write [ anon ] E1800000 18400 10472 - 10472 read/write [ anon ] E2C00000 7096 3408 - 3408 read/write [ anon ] E3C00000 16344 7024 - 7024 read/write [ anon ] E4C00000 11448 4840 - 4840 read/write [ anon ] E5800000 14512 5504 - 5504 read/write [ anon ] E6800000 16344 5832 - 5832 read/write [ anon ] E7C00000 10152 4912 - 4912 read/write [ anon ] E8800000 12888 5320 - 5320 read/write [ anon ] E9800000 26208 9048 - 9048 read/write [ anon ] EB400000 26208 8528 - 8528 read/write [ anon ] ED000000 7096 2200 - 2200 read/write [ anon ] ED800000 4936 2536 - 2536 read/write [ anon ] EE000000 33192 7864 - 7864 read/write [ anon ] F0400000 7096 1776 - 1776 read/write [ anon ] F0C00000 20704 5552 - 5552 read/write [ anon ] F2400000 37368 6144 - 6144 read/write [ anon ] F4C00000 26208 3944 - 3944 read/write [ anon ] F6C00000 6304 1688 - 1688 read/write [ anon ] F7400000 5584 3360 - 3360 read/write [ anon ] F7C00000 26208 6592 - 6592 read/write [ anon ] F9800000 10152 1144 - 1144 read/write [ anon ] FA400000 9000 2304 - 2304 read/write [ anon ] FB000000 5584 1496 - 1496 read/write [ anon ] FB800000 9000 1400 - 1400 read/write [ anon ] FC400000 7096 1720 - 1720 read/write [ anon ] FCC00000 16344 2272 - 2272 read/write [ anon ] FDC80000 3848 3080 - 3080 read/write [ anon ] FE080000 3856 352 - 352 read/write [ anon ] FE700000 720 664 - 664 read/write [ anon ] FE880000 1032 992 - 992 read/write [ anon ] FE9B0000 344 336 - 336 read/write [ anon ] FEA60000 8 8 - 8 read/write [ anon ] FEA70000 8 8 - 8 read/write [ anon ] FEA80000 360 344 - 344 read/write [ anon ] FEAE0000 344 336 - 336 read/write [ anon ] FEB60000 8 - - - read/write [ anon ] FEB80000 8 - - - read/write [ anon ] FEB90000 8 - - - read/write [ anon ] FEBA0000 8 8 - 8 read/write [ anon ] FEBB0000 16 16 8 8 read/exec libmp.so.2 FEBC2000 8 8 8 - read/write/exec libmp.so.2 FEBD0000 80 24 16 8 read/exec libICE.so.6 FEBF2000 8 - - - read/write/exec libICE.so.6 FEBF4000 8 - - - read/write/exec [ anon ] FEC00000 656 608 592 16 read/exec libc.so.1 FECB2000 32 32 - 32 read/write/exec libc.so.1 FECC0000 8 8 - 8 read/write [ anon ] FECD0000 16 16 8 8 read/exec libc_psr.so.1 FECE0000 40 16 8 8 read/exec libSM.so.6 FECF8000 8 - - - read/write/exec libSM.so.6 FED00000 512 384 368 16 read/exec libnsl.so.1 FED8E000 40 40 - 40 read/write/exec libnsl.so.1 FED98000 32 8 - 8 read/write/exec [ anon ] FEDB0000 8 8 - 8 read/write/exec [ anon ] FEDC0000 24 24 16 8 read/exec libgen.so.1 FEDD4000 16 16 - 16 read/write/exec libgen.so.1 FEDE0000 32 32 24 8 read/exec libsocket.so.1 FEDF6000 16 16 - 16 read/write/exec libsocket.so.1 FEE00000 88 72 64 8 read/exec libm.so.1 FEE24000 8 8 8 - read/write/exec libm.so.1 FEE30000 168 72 - 72 read/exec libcurses.so.1 FEE68000 40 8 - 8 read/write/exec libcurses.so.1 FEE72000 8 - - - read/write/exec [ anon ] FEE80000 8 - - - read/write [ anon ] FEE90000 448 440 432 8 read/exec libX11.so.4 FEF00000 24 24 - 24 read/write/exec libX11.so.4 FEF10000 336 336 320 16 read/exec libXt.so.4 FEF74000 24 24 - 24 read/write/exec libXt.so.4 FEF7A000 8 8 - 8 read/write/exec [ anon ] FEF80000 488 112 104 8 read/exec libtt.so.2 FF00A000 48 - - - read/write/exec libtt.so.2 FF020000 80 72 64 8 read/exec libXext.so.0 FF042000 8 8 8 - read/write/exec libXext.so.0 FF050000 8 8 - 8 read/write/exec [ anon ] FF060000 80 56 48 8 read/exec libXmu.so.4 FF082000 16 16 - 16 read/write/exec libXmu.so.4 FF090000 384 192 160 32 read/exec libDtSvc.so.1 FF0F0000 24 24 - 24 read/write/exec libDtSvc.so.1 FF100000 2032 1160 1048 112 read/exec libXm.so.4 FF30C000 96 88 - 88 read/write/exec libXm.so.4 FF330000 56 8 - 8 read/exec libXpm.so.4.6 FF34C000 8 - - - read/write/exec libXpm.so.4.6 FF360000 160 40 - 40 read/exec libpng.so.2.1.0 FF396000 16 - - - read/write/exec libpng.so.2.1.0 FF3A0000 8 8 - 8 read/exec libdl.so.1 FF3B0000 120 120 112 8 read/exec ld.so.1 FF3DC000 8 8 - 8 read/write/exec ld.so.1 FF3DE000 8 8 - 8 read/write/exec [ anon ] FFBCC000 144 88 - 88 read/write/exec [ stack ] -------- ------ ------ ------ ------ total Kb 576464 242832 3416 239416

6 participants
14 comments

wierd color problem with xemacs-21.0-b57 27 years

David Wang

Here is a weird one with xemacs-21.0-b57 under solaris 2.5.1: I start up a TTY xemacs server session with gnuserv-start. I then use gnuclient to open up one X frame. The face colors are the ones that I've specified in my .emacs file and correct. If I then use "C-x 5 b" to open up another x frame, the 2nd X frame face colors are all screwed up. If I do the reverse, ie start up a X xemacs server, and then do "gunclient -nw" to create a tty frame and then from within the tty frame do a "C-x 5 b", my tty colors become screwed up. Here is how I set up my faces in my .emacs. I have one set of faces for my tty frames and another one for the x frames. I'm wondering if thats the problem and if there is a solutions? -- .emacs -- (custom-set-variables '(paren-mode (quote paren) nil (paren)) '(column-number-mode t) '(lazy-shot-mode t nil (lazy-shot)) '(visible-bell t) '(toolbar-visible-p nil) '(scrollbars-visible-p nil) '(line-number-mode t) '(font-lock-mode t nil (font-lock))) (custom-set-faces '(info-node ((((type x)) (:foreground "yellow")) (((type tty)) (:foreground "brightyellow")))) '(red ((((type x)) (:foreground "orange")) (((type tty)) (:foreground "brightmagenta")))) '(font-lock-string-face ((((type x)) (:foreground "moccasin")) (((type tty)) (:foreground "brightwhite")))) '(font-lock-reference-face ((((type x)) (:foreground "medium spring green")) (((type tty)) (:foreground "brightgreen")))) '(custom-group-tag-face ((((type x)) (:foreground "cyan")) (((type tty)) (:foreground "brightcyan")))) '(custom-variable-tag-face ((((type x)) (:foreground "yellow")) (((type tty)) (:foreground "brightyellow")))) '(font-lock-doc-string-face ((((type x)) (:foreground "thistle")) (((type tty)) (:foreground "magenta")))) '(custom-group-tag-face-1 ((((type x)) (:foreground "pink")) (((type tty)) (:foreground "brightred")))) '(modeline-buffer-id ((((type x)) (:foreground "white" :background "#c06077")) (((type tty)) (:foreground "white" :background "yellow")))) '(font-lock-preprocessor-face ((((type x)) (:foreground "medium spring green")) (((type tty)) (:foreground "brightgreen")))) '(modeline-mousable ((((type x)) (:foreground "white" :background "#c06077")) (((type tty)) (:foreground "white" :background "yellow")))) '(font-lock-variable-name-face ((((type x)) (:foreground "moccasin")) (((type tty)) (:foreground "brightwhite")))) '(paren-match ((((type x)) (:foreground "cyan" :background "blue4")) (((type tty)) (:foreground "brightcyan" :background "blue")))) '(modeline-mousable-minor-mode ((((type x)) (:foreground "white" :background "#c06077")) (((type tty)) (:foreground "white" :background "yellow")))) '(custom-face-tag-face ((((type x)) (:foreground "yellow")) (((type tty)) (:foreground "brightyellow")))) '(custom-state-face ((((type x)) (:foreground "moccasin")) (((type tty)) (:foreground "brightwhite")))) '(font-lock-keyword-face ((((type x)) (:foreground "yellow")) (((type tty)) (:foreground "brightyellow")))) '(font-lock-type-face ((((type x)) (:foreground "pink")) (((type tty)) (:foreground "brightred")))) '(bold-italic ((t nil)) t) '(list-mode-item-selected ((((type x)) (:foreground "yellow" :background "firebrick")) (((type tty)) (:foreground "brightyellow" :background "cyan")))) '(italic ((t nil)) t) '(font-lock-comment-face ((((type x)) (:foreground "orange")) (((type tty)) (:foreground "brightmagenta")))) '(font-lock-function-name-face ((((type x)) (:foreground "cyan")) (((type tty)) (:foreground "brightcyan")))) '(isearch ((((type x)) (:foreground "yellow" :background "firebrick")) (((type tty)) (:foreground "brightyellow" :background "cyan")))) '(highlight ((((type x)) (:foreground "black" :background "darkseagreen2")) (((type tty)) (:foreground "brightyellow" :background "cyan")))) '(modeline ((((type x)) (:foreground "white" :background "#c06077")) (((type tty)) (:foreground "white" :background "yellow")))) '(zmacs-region ((((type x)) (:foreground "yellow" :background "firebrick")) (((type tty)) (:foreground "brightyellow" :background "cyan")))))

5 participants
10 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 1998