July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Michael Sperber

Anyone else seeing this? Fatal error: assertion failed, file /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-21.2/src/symbols.c, line 3190, UNBOUNDP (XSYMBOL (sym)->function) make[1]: *** [update-elc.stamp] IOT/Abort trap (core dumped) This is AIX 4.2.1, egcs 1.1.2. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Michael Sperber

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> Again, I don't want to mess with the high-level directory >> organization. I don't particularly care one way or another, and I'll >> let someone else sort out that particular mess. dv> Yes please, people, speeeak! Mickael and I know pretty well now that dv> we disagree on this. Didier, I think there's a big misunderstanding here: Sure, I disagree with you. But that's mainly because our software installation setup is different from yours, and the present scheme fits ours pretty well. I don't think that it makes much of a difference which setup we choose, which is why I believe we might just as well leave it unchanged. I won't change it. If you want to change it, go ahead. As long as it doesn't hurt anyone more than it does currently, I won't be in your way. The root of all evil here is, of course, once again, hierarchical file systems which hopefully will be among the first things against the wall when the revolution comes (along with syntax tables, read-time macros and a few other things). Given that noone really bothered since the days of Unix, we better use what we have. Please let me design the package system in such a way that it doesn't need to care about these issues. If you want granularity, put packages wherever your high-levels setup tells you to. If you get duplication that way but want sharing, use links. That's precisely what they've been designed for. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

XEmacs 21.2.18 -- "豊島" is released 25 years, 4 months

SL Baur

Get it from the usual places: ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ http://cvs.xemacs.org/ I am having connectivity problems again with cvs, hopefully it is just the Japanese phone company again and it will be fixed soon. New XEmacs lisp packages have been uploaded as well. The new Sumos are in: ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz New and highly-changed packages include lookup (a very cool Japanese dictionary front end), new mailcrypt with gpg support, ps-print-nomule (a forked old version of ps-print, but one that still works with XEmacs/noMule). egg-its has some major bug fixes. calendar now supports Japanese calendars. "Toshima" is a ward of Tokyo where the Sunshine Namjatown theme park is. The English descriptions of the rides were done by someone who does not speak English and some very interesting translations are made. For example, the Katori Daisakusen[1] ride has the description: "Save the district from huge mosquitoes that were bred in vast quantities! Ride an unglazed pig and kill mosquitoes with a spray gun." 21.2.19 "name TBD, maybe Shinjuku" is tentatively scheduled for Friday, but will probably end up being some time early next week. There is more InfoDock synchage to do, and 21.2.19 will definitely come after InfoDock 4.0.8. to 21.2.18 "Toshima" -- miscellaneous fixes from Steve Baur -- miscellaneous fixes from Didier Verna -- various bug fixes from Karl Hegbloom -- miscellaneous fixes from Bob Weiner -- fix for XIM server crashing and taking down XEmacs from Kazuyuki IENAGA -- valid-image-instantiator-format-p tightened up by Andy Piper. -- glyph widget support under X/Motif from Andy Piper -- Make docdir configurable, update package searching rules from Michael Sperber -- Fix for Japanese word/character movements from MORIOKA Tomohiko -- lrecord struct header size fix from Olivier Galibert Footnotes: [1] This is left untranslated in the English guide. -- 屁をひって尻窄め (It's useless to close the barn door after the horse has left)

1 participants
0 comments

Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) 25 years, 4 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > karlheg(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: ... >> I don't think it's a major change. It's a small patch. It's not >> complicated. > Has it occurred to you that you could be wrong? I will add that some of our most bitter flame wars have been over single line patches, for example, the single line patch to screw up the delete key. ... Jan> Note that the issues here are _not_ easy to solve (you do Jan> know that what you describe was in the XEmacs betas once and Jan> was taken out again, do you?). >> >> Yes... I missed the `why' part. Why was it taken out? > Partly because noone could think of a good migration path. Exactly. We have not figured out a way to not make it suck. If you put it into Debian-XEmacs we will have the situation we have been trying to avoid -- multiple highly incompatible flavors of XEmacs. I hope we can make it work as the current situation is suboptimal, but please reconsider your decision on this. -- 蛙の子は蛙 (Like father, like son)

1 participants
0 comments

Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) 25 years, 4 months

Hrvoje Niksic

I missed the beginning of the thread, which apparently originated at debian-devel. I assume Karl wants to re-introduce ~/.xemacs/init.el and ~/.xemacs/options.el files in the Debian version of XEmacs. karlheg(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > >> I disagree, and will ship the package with the modification. > >> Don't bother filing a bug about it... This is a minor change, > >> not a hairy major code fork. It's not a meaningful political > >> act, just part of the job I'm doing. > > Jan> No. This is a MAJOR user interface change. And frankly, I > Jan> think it is _not_ part of the job you are doing. If you want > Jan> to help develop XEmacs thats more than OK with me. But please > Jan> use the regular channels for that and not use your position > Jan> as a Debian for that. > > I don't think it's a major change. It's a small patch. It's not > complicated. Has it occurred to you that you could be wrong? If a patch is "small", it doesn't mean that its effects are negligible. Either way, it's an important *interface* change. As a matter of principle, Debian maintainers should not indulge in such things. I was kind of hoping that having a familiar (your) face for the Debian maintainer would improve things, not make them worse. > It's silly to expect newbies (there will be many installing the > package) to edit `~/.emacs/' codes, and to maintain two branches > inside of it to cope with both GNU Emacs and XEmacs. Karl, just what are you talking about? The file is named `~/.emacs', and the newbies have edited it for ages, along with the experienced users. Since when has it become "silly"? Is it a new Debian fashion that the rest of us simply can't understand? > Jan> Note that the issues here are _not_ easy to solve (you do > Jan> know that what you describe was in the XEmacs betas once and > Jan> was taken out again, do you?). > > Yes... I missed the `why' part. Why was it taken out? Partly because noone could think of a good migration path. > (I will spend a few minutes looking for that in the > archive... <sigh> I WILL NOT work late today. My health is more GD > important than sitting here working for no income. Of course it is. But: if you don't have time to do the work, don't take the responsibility. Sorry.

1 participants
0 comments

xemacs 21.2.17 on Solaris 7 64bit hangs 25 years, 4 months

Rajesh Godbole

The following message is a courtesy copy of an article that has been posted to sun.emacs as well. Compiled xemacs 21.2.17 on Solaris 7 in 64bit mode using Sun Workshop 5.0. Now it occasionally hangs while trying to load cus-edit.el, So I decided to re-compile lisp files. Compilation of lisp files hangs while compiling lisp/cus-edit.el: Checking for Mule support... Yes Compiling files without .elc... /usr/local/src/gnu/xemacs/xemacs-21.2.17/src/xemacs -batch -vanilla -f batch-byte-compile lisp/./cus-edit.el lisp/./cus-face.el lisp/./cus-load.el lisp/./custom-load.el lisp/./disass.el lisp/./disp-table.el lisp/./etags.el lisp/./files-nomule.el lisp/./finder-inf.el lisp/./finder.el lisp/./font-lock.el lisp/./font-menu.el lisp/./font.el lisp/./gnuserv.el lisp/./help-macro.el lisp/./help-nomule.el lisp/./hyper-apropos.el lisp/./info.el lisp/./ldap.el lisp/./lisp-mnt.el Compiling /home/rajesh/src/gnu/xemacs/xemacs-21.2.17/lisp/cus-edit.el... Loading customization dependencies...<hangs> truss shows: 20131/1: getcontext(0xFFFFFFFF7FFF88E0) 20131/1: getcontext(0xFFFFFFFF7FFF88E0) 20131/1: stat("/usr/local/lib/xemacs/packages/lisp/pc/custom-load.elc", 0xFFFFFFFF7FFF8A40) = 0 20131/1: access("/usr/local/lib/xemacs/packages/lisp/pc/custom-load.elc", 4) = 0 20131/1: getcontext(0xFFFFFFFF7FFF88E0) Installation: uname -a: SunOS einstein 5.7 Generic_107605-02 sun4u sparc SUNW,Ultra-5_10 ./configure 'sparc-sun-solaris2' '--verbose' '--site-includes=/usr/local/include' '--site-runtime-libraries=/usr/local/lib' '--with-site-lisp=yes' '--with-workshop=yes' '--with-mule=yes' '--with-ldap=yes' '--with-sound=no' '--x-libraries=/usr/openwin/lib/sparcv9' XEmacs 21.2-b17 "Chiyoda" configured for `sparc-sun-solaris2'. Where should the build process find the source code? /home/rajesh/src/gnu/xemacs/xemacs-21.2.17 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? cc -xO3 -xtarget=ultra2i -xcache=16/32/1:256/64/1 -xarch=v9 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib/sparcv9 Additional header files: /usr/local/include Runtime library search path: /usr/local/lib Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in support for LDAP. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for Sun WorkShop. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Any ideas where to start poking? -rajesh

1 participants
0 comments

Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.) 25 years, 4 months

Karl M. Hegbloom

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Karl, did you miss the whole "Debian packagers do their own Jan> thing flamefest? There's only so much time in a day. I've pile of books I want to read, exercises to do in them, and I've got to eat, which means doing a job as well. Reading a flamewar isn't a high priority, sorry. >> I disagree, and will ship the package with the modification. >> Don't bother filing a bug about it... This is a minor change, >> not a hairy major code fork. It's not a meaningful political >> act, just part of the job I'm doing. Jan> No. This is a MAJOR user interface change. And frankly, I Jan> think it is _not_ part of the job you are doing. If you want Jan> to help develop XEmacs thats more than OK with me. But please Jan> use the regular channels for that and not use your position Jan> as a Debian for that. I don't think it's a major change. It's a small patch. It's not complicated. It's not extensive. >> I will, after developing something that works and looks good, >> submit patches "upstream", for certain. They will be reviewed, >> and perhaps will become part of XEmacs 21.2 or 21.3, depending >> upon timeing and whatever-it-takes. It's not a strange new >> idea. Jan> No it isn't. Including your experimental patches in a major Jan> distribution is. Even more if you are going to ignore bug Jan> reports about it. Distribution packages are not the right Jan> place to do beta testing. It's silly to expect newbies (there will be many installing the package) to edit `~/.emacs/' codes, and to maintain two branches inside of it to cope with both GNU Emacs and XEmacs. Granted, they will likely stick to one or the other, but will try both to begin with. Jan> Note that the issues here are _not_ easy to solve (you do Jan> know that what you describe was in the XEmacs betas once and Jan> was taken out again, do you?). Yes... I missed the `why' part. Why was it taken out? (I will spend a few minutes looking for that in the archive... <sigh> I WILL NOT work late today. My health is more GD important than sitting here working for no income. I have studies I want to complete also.) >> At any rate... I really ought to be working on the thing >> instead of inspiring flame wars over it and wasting our >> development/study time on email. Jan> No you _need_ to spend time on email first. You _need_ to Jan> discuss the design. I will send the patch for review (to xemacs-patches); I'll try and get to it today so yous can view it.

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Karl M. Hegbloom

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> Well, we're talking about two different things here: first dv> separating architecture-dependant stuff, and secondly dv> /sharing/ what can be shared. Michael> Sure, but that's mostly a high-level organizational Michael> issue, and different systems address the issue in Michael> different ways. You cater to one, you hurt the others. dv> Here, we have a /usr/local/share[1] directory which is dv> automounted from a single machine onto the others. It's really dv> comfortable to install stuff under it, knowing that all dv> machines will immediately see it. From a sysadmin point of dv> view, installing architecture independant stuff for XEmacs dv> packages under this directory would be dv> straightforward. However, imagine the pain it would be to dv> update all machines on a site to make them mount dv> /whatever/xemacs-packages/foo-1.32/lisp each time such a dv> package is installed. Michael> I'm afraid I don't understand the point you're making. Michael> If a package contains architecture-depdendent stuff, you Michael> obviously need to install at least parts of it somewhere Michael> other than /usr/local/share if you want to preserve the Michael> integrity of your setup. I don't know if that means Michael> requiring explicit mounts, but that doesn't really Michael> matter. Why not install the whole thing somewhere else Michael> then? If you want sharing in your setup, that's what Michael> symbolic links are for. They are trivially managed by a Michael> set of two shell scripts. I think it would work best to make each of the directories a configurable option, so that the site admin or package builder can decide where to install stuff. Isn't that how things are normally done anyhow? I'd put the cross architecture shareables under .../share/..., and the binary modules under .../lib/..., perhaps by using --switches to `configure' if that exists, (with a default that follows the LHS or GNU Coding Standards filesystem layout would be best). That's what Didier is talking about, I think. Here there's /usr/share/emacs/{20.{2,3},site-lisp}/, and /usr/lib/emacs/20.3/i386-debian-linux-gnu/ from the Emacs 20 (i386) Debian package. I suppose that on a server, there could be subdirs there in lib for other architectures, and that you'd have .../arch-bin directories that get mounted on the client hosts as just .../bin. So I think there needs to be a configurable way of installing. Perhaps as root, an XEmacs site admin could run the package installer thing, after having configured site directories using `customize' widgetry, have it fetch the tarfile for per architecture, and it would unpack it someplace temporary, then move the subdirs inside it into the set locations. To make a debian package of something, I build a sub-filesystem (rooted at "$(pwd)/debian", pretending to be "/") and move the stuff into it, as if ready to form a .tar, then let the packaging tools pack that up. When somebody installs it, everything will go where it belongs, since the tarfile inside the .deb will essentially be opened from "/". What about stuff that assumes something resides in a certain location? Usually that's solved by using --prefix, --libdir, --statedir, etc. with `configure', then installing to the pseudo-root with `make PREFIX=$(pwd)/debian/tmp ... install'. This way the insides have the actually after-actual-installation paths, but the install target puts things into your staging directory. (as designed.) I hope this proves I've learned something.

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 25 years, 4 months

Hrvoje Niksic

karlheg(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > I was going to demo the ispell completion the other day, and it > blonked at me... the error happens when there's more than a certain > number of completions, and in that code, it uses a > char-to-int/int-to-char conversion... it increments a char var to > form the keys you push to select which completion you want to use. I don't think this has anything to do with the subject of the message. > To repeat: In a `message' buffer, (I think the ispell complete is > on by default... or maybe I have it switched on someplace?), type > `hel' and push `M-Tab'. It signals an error. Yes, it's on by default, but no, it doesn't signal an error to me. I use "ispell.el 3.0 -- Fri Mar 20 13:25:59 PST 1998".

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Karl M. Hegbloom

<URL:http://bittersweet.sysc.pdx.edu/doc/emacsen-common/> may also be of interest. This is a pre-xemacs21 way of dealing with installing Lisp for multiple emacs versions. The lisp is byte-compiled at installation time. The source is available via debian.org... it's a 20 minute read at most; probably less time than that for most of you.

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 July 1999