October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: about the packages: directory names and places 26 years, 1 month

Holger Schauer

>>>>"SJT" == Stephen J Turnbull schrieb am Tue, 13 Oct 1998 13:57:23 +0900 (JST): SJT> (a) as Michael pointed out, many, probably the majority, of SJT> existing hosts don't have .../share/; enforcing it will confuse SJT> their users and admins, and could be annoying if the local SJT> XEmacs maintainer doesn't have rights to the .../ directory This isn't really a problem, is it ? The key idea would be to check for the /share-directory (and of course to check whether one is allowed to write on it) and to use /lib otherwise as the default. I certainly like the idea (mostly running Linux), although I also like a package of the size of XEmacs not to spread its various files all over /. Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "Keine Shell, kein Prompt, keine Kekse." -- Jochen Hein in de.comp.os.linux.misc

1 participants
0 comments

[Crash] Various betas with optimization 26 years, 1 month

Marcus Thiessel

I get reproducable crashes with various betas (21.0-b57, 21.0-prelim, 21.2-b2) and optimization. The strange things is that these errors which are reported as Pid 5479 killed due to trashed stack. Pid 5479 was killed due to failure in writing the signal context. [2] Illegal instruction /opt/src/xemacs-21.0-b57/src/xemacs -f vm (core dumped) are always placed around calls to make_uninit_string () (gdb) where #0 0xc00f2240 in _brk () from /usr/lib/libc.2 #1 0xc00fb514 in sbrk () from /usr/lib/libc.2 #2 0x24bb98 in __default_morecore () #3 0x24a3d8 in morecore () #4 0x24aca8 in malloc () #5 0x62b90 in make_uninit_string () #6 0x632d8 in make_string () #7 0x14afb8 in 291_12d6_cl_concat () #8 0xc0 in TBS$pngrtran () #9 0xc00fb514 in sbrk () from /usr/lib/libc.2 (gdb) where #0 0x62b24 in make_uninit_string () #1 0x632d8 in make_string () #2 0x14afb8 in 291_12d6_cl_concat () #3 0x40177014 in ?? () #4 0x632d8 in make_string () Are there any related problems known so far? --Marcus BTW, any reason why --error-checking=all doesn't work with configure anymore?

1 participants
0 comments

Re: about the packages: directory names and places 26 years, 1 month

Michael Sperber

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> You can't force ~/.xemacs to be *THE* user-local package directory by dv> default because the user should be able to do what it wants in this dv> directory. I for instance have other subdirs like autosave/, drafts/ and dv> others, and I had a lisp/ dir for stuff not being in any package (code under dv> development, random hacks ...). I would then prefer to have a packages/ subdir dv> under ~/.xemacs/, and use it to install packages locally. >From etc/NEWS: IMPORTANT NOTE: XEmacs currently expects the user-specific package hierarchy in ~/.xemacs. This will probably change to ~/.xemacs/packages in a future version of XEmacs. dv> To stay coherent in the placement scheme, this also means that I'd dv> prefer to see a packages/ subdir, everywhere packages could be installed. In dv> other words, instead of having site-packages, mule-packages and dv> xemacs-packages under ${prefix}/lib/xemacs/, I'd prefer to see dv> ${prefix}/lib/xemacs/packages/ and then site/ mule/ and xemacs/[2]. But the rationale behind the current naming scheme is different: The directory names `xemacs-packages' and `mule-packages' correspond to features `xemacs' and `mule.' Steve had some further development of this in mind. This is also why this sort of naming "scheme" does not apply to ~/.xemacs/packages. dv> 2/ Importance: 3/5 dv> The name xemacs-packages is not informative for people: all packages dv> are for xemacs. This is only currently so. Ultimately, this is meant to be complemented by `infodock-packages', `emacs-packages' (or `fsf-packages' :-} ) and so on. dv> 3/ Importance: 4/5 dv> The presence of the mule subdir appears questionable to me: this dv> separation is put on the same level as the site-level or distrib-level split, dv> but it has nothing to do with it. Consider this: dv> - having site-packages is good, not only because you can put random dv> stuff not in the distribution, but because it will allow you to override any dv> packages already installed in the standard place (xemacs-packages) with dv> something newer, locally modified, of a different flavor or whatever. For mule dv> stuff this doesn't appear possible, since all mule stuff is supposed to go in dv> the mule-packages directory. dv> - if somebody writes a new package for mule, where does it go ? under dv> site-packages or under mule-packages ? This is ambiguous. This is a very good point. I'll think about this. dv> 4/ Importance: 5/5 dv> Currently, the default prefix is ${prefix}/lib/xemacs. There, I'm dv> gonna be very direct, sorry, but this is the *WRONG* place. Everything in dv> packages is architecture independant: Huh? The architecture-*dependent* stuff is under a subdirectory with the name of the architecture. Nothing in the name "lib/xemacs" suggests architecture-dependence. Of all the 150+ software packages I've installed, only 10 even *have* a `share' directory, but plenty have architecture-independent stuff in `lib.' Plus, you can change the locations of pretty much everything via configure. So, given the fact that there are no standards as to the directory structure of Unix software, I claim that this particular way of doing it is at least as good as any other. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

files with extension .EL ?? 26 years, 1 month

Martin Buchholz

mule-base-1.24-pkg.tar.gz seems to contain files that have the extension .EL instead of .el: lisp/mule-base/ethio-util.EL lisp/mule-base/ethiopic.EL lisp/mule-base/vietnamese.EL Martin

1 participants
0 comments

XEmacs package update 1998-10-12-2 26 years, 1 month

SL Baur

Out, out damned spot! The package-get-base.el file is at: ftp://ftp.xemacs.org/pub/xemacs/packages/package-index-1998-10-12-2 There were two mule-base packages uploaded today. mule-base-1.23 is poison, do not use it. mule-base-1.24 is O.K. When removing the old mule-base watch out for two files which don't get installed with write permission. bbdb has been repackaged to include some .tex files that have been omitted from previous packagings. pcl-cvs has been updated with some bug fixes. The other changed packages gnus, pgnus, mew, and zenirc were repackaged. XEmacs.rules has been updated. Please give this a try and scream at me if anything goes wrong.

1 participants
0 comments

Re: [CRASH] xemacs-21.2-b2 in pgnus 26 years, 1 month

SL Baur

Andrew Hobson <ahobson(a)eng.mindspring.net> writes in xemacs-beta(a)xemacs.org: > On 12 Oct 1998 15:03:54 -0700, SL Baur <steve(a)xemacs.org> said: >> These are the identical symptoms to the bug I might have isolated a >> test case for and posted about last week. Does uudecdoing the XEmacs >> killer jpeg crash XEmacs for you? > No. I tried it with both FreeBSD's uudecode and GNU's uudecode from > sharutils-4.2. The killer jpeg causes uudecode to exit immediately with > an error. My FreeBSD uudecode reports: > uudecode: stdin: illegal ~user > So on a hunch, I replaced my uudecode with: > #!/bin/sh > exit 0 > I immediately got a crash. That would be positive ... > But I just tried it three more times and I didn't. ... but that isn't. > I know I'm stating the obvious, but I guess it's a race condition. Yes, that is likely. The code says there's a SIGPIPE handler installed, but somehow it sometimes isn't. In my case, the killer jpeg is a sure kill. This bug isn't new. It's been around for a long time -- at least back to 20.3, I think. > Come to think of it, after my initial crash, I did a netstat -t and I > noticed that I didn't have a connection to the news server. I didn't > think much about it at the time.

1 participants
0 comments

Re: [CRASH] xemacs-21.2-b2 in pgnus 26 years, 1 month

Andrew Hobson

On 12 Oct 1998 15:03:54 -0700, SL Baur <steve(a)xemacs.org> said: > These are the identical symptoms to the bug I might have isolated a > test case for and posted about last week. Does uudecdoing the XEmacs > killer jpeg crash XEmacs for you? No. I tried it with both FreeBSD's uudecode and GNU's uudecode from sharutils-4.2. The killer jpeg causes uudecode to exit immediately with an error. My FreeBSD uudecode reports: uudecode: stdin: illegal ~user So on a hunch, I replaced my uudecode with: #!/bin/sh exit 0 I immediately got a crash. But I just tried it three more times and I didn't. I know I'm stating the obvious, but I guess it's a race condition. Come to think of it, after my initial crash, I did a netstat -t and I noticed that I didn't have a connection to the news server. I didn't think much about it at the time. Drew -- "Right Side! Right Side!" "I don't think they can hear you." -- L.A. Story

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

greg(a)alphatech.com (Greg Klanderman) writes: > haven't decided if i like that yet, but it leaves the mark on the > far side of (point) and (mark) when you move to beginning or end of > buffer. Yup. To be precise, it doesn't change the mark at all, when the region is active. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

1 participants
0 comments

Re: about the packages: directory names and places 26 years, 1 month

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > LOTS of GNU packages install arch-independent stuff into lib: > > emacs (good to be compatible here!) Huh? FSF Emacs has used share for ages! The rest you mentioned aren't GNU packages. > perl5 > tcl > rpm > python > ... -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Jone's law: The man who smiles when things go wrong has thought of someone to blame it on.

2 participants
1 comments

Re: Why using (push-mark) ? 26 years, 1 month

Greg Klanderman

haven't decided if i like that yet, but it leaves the mark on the far side of (point) and (mark) when you move to beginning or end of buffer. greg >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Hrvoje> greg(a)alphatech.com (Greg Klanderman) writes: >> (defun gk:beginning-of-buffer () >> "Move point to the beginning of the buffer." >> (interactive "_") >> (if zmacs-region-active-p >> (if (> (point) (mark)) >> (exchange-point-and-mark)) >> (push-mark)) >> (goto-char (point-min))) Hrvoje> Hrvoje> I don't understand your (> (point) (mark)) check. If I were to change Hrvoje> beginning-of-buffer, I'd make a simpler change: Hrvoje> Hrvoje> (defun ... Hrvoje> (interactive "_") Hrvoje> (unless (region-active-p) Hrvoje> (push-mark)) Hrvoje> ;; the rest of the function -- a bit more complex than this, but Hrvoje> ;; essentially the same: Hrvoje> (goto-char (point-min)))

1 participants
0 comments

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 October 1998