July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released 25 years, 4 months

Michael Sperber

>>>>> "Colin" == Colin Rafferty <craffert(a)ms.com> writes: Colin> Michael Sperber writes: >>>>>>> "Colin" == Colin Rafferty <craffert(a)ms.com> writes: Colin> hobbes $ cvs update Colin> cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused >> Seems to me your cvs pserver port is wrong; it's 2401, not 2410. Colin> Good point. Colin> So I have no control over cvs at my job. More likely, it's the cvspserver entry in /etc/services or the services map. 2410 is definitely *wrong* and should be fixed. Colin> Do you happen to know how I can change the port from the Colin> command line (or .cvsrc or .cvspass or ...)? You can't. Your best bet is probably to recompile CVS yourself. -- 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: >> 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. dv> [...] You'd understood that it doesn't fit mine. Ah! No, I hadn't. Please explain why. dv> That's disapointing as well as worrying to hear that. It sounds like dv> you're closed to any discussion on this just because it is a problem (or a dv> feature) you just don't want to care about. I don't even see your problem yet. I think it's wrong to intermingle the design issues concerning the package layout with the global issues of XEmacs directory layout. If you make one depend on the other, it's much harder to make local changes. I want to be working on the package system, not the global directory layout. For the directory layout issues, I don't stand a chance against you, and I don't want to. Moreover (and please acknowledge this, Didier), there are software setups *other* than yours (notably, ours) where hard-wiring what you're suggesting is going to royally fuck things up. At the file system level, a package constitutes a collection of files that belong together. With hierarchical file systems, the *only* way to reflect "togetherness" (as well as "apartness" from other packages, say) is to put those files into a common subdirectory which is not a subdirectory containing other packages. This has a number of advantages, two being ease of installation and un-installation as well as an easy-to-satisfy integrity criterion. The latter point is especially important since I can check package integrity *locally*, and it's pretty hard to violate it without seeing what you're doing. Once the package is spread out as you suggest, installation is still easy enough, but suddenly, if I want to uninstall or move or ship a package, I have to remember where all its bits are. If I forget some of them, there's no guarantee the system will *ever* notice that fact. dv> Again, I'm sorry, but no way. This is like doing consciously something dv> wrong first, and then reparing the damage afterwards. I'm not ready to make dv> dozens of symlinks even if it's automatized in any fashion. Well, so there. I'm not ready to spread packages over disparate portions of the hierarchy. Seriously, links *are* Unix's native mechanism for expressing sharing. You may not like it, but it's the only thing there is. They're not exactly a neat design, but they're excruciatingly easy to manage automatically. Yet another solution for achieving maximum sharing without links is to factor the architecture-specific portions of a larger packages into packages of their own. This makes sense for staging reasons as well. Stick the architecture-independent bit into a shared package hierarchy, and the architecture-specific bit into one conditionalized on architecture. dv> But please, don't say things like "I won't change it". I never said that. How come you claim this? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

[Success] 21.2 (beta18) "Toshima" XEmacs Lucid on i686-pc-cygwin 32 25 years, 4 months

Michael Hill

>From CVS, edited event-msw.c to reflect Andy's cygwin b19 fix from b17. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /binary/xemacs-21.2/Installation: > (Output from most recent run of ./configure) uname -a: CYGWIN32_NT DILBERT 4.0 19.4 i686 unknown ./configure '--package-path=/binary/xemacs-20' '--site-includes=/usr/local/include' '--cflags=-O2' XEmacs 21.2-b18 "Toshima" configured for `i686-pc-cygwin32'. Where should the build process find the source code? /binary/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/cygwin32.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O2 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? default What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6.3/include Where do we find X Windows libraries? /usr/X11R6.3/lib Additional header files: /usr/local/include Compiling in support for XAUTH. 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 TIFF image handling. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in File coding support. Compiling in EXPERIMENTAL support for Drag'n'Drop ( msw ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. 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: --------------------------------------------------------- > /binary/xemacs-21.2/beta.err does not exist!

1 participants
0 comments

Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released 25 years, 4 months

Colin Rafferty

Michael Sperber writes: >>>>>> "Colin" == Colin Rafferty <craffert(a)ms.com> writes: Colin> hobbes $ cvs update Colin> cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused > Seems to me your cvs pserver port is wrong; it's 2401, not 2410. Good point. So I have no control over cvs at my job. Do you happen to know how I can change the port from the command line (or .cvsrc or .cvspass or ...)? Thanks. -- Colin

1 participants
0 comments

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

Didier Verna

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > 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'd understood this. You'd understood that it doesn't fit mine. > 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 beleive it makes a difference and that's why I'm arguing about this. > 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. > [...] > Please let me design the package system in such a way that it doesn't > need to care about these issues. That's disapointing as well as worrying to hear that. It sounds like you're closed to any discussion on this just because it is a problem (or a feature) you just don't want to care about. But you're designing the whole thing again and it's gonna have a very important impact on the future of XEmacs. What I'm trying to do is only addressing a problem which I find important *before* the new design is actually implemented, even if I'm not the one who's implementing it. I don't feel like changing anything after you. I feel like designing things the Right Way before hacking them. Please note that I'm probably never going to use the package stuff as it will be designed (appart from at home which is a single machine anyway). I've got everything locally under my account on my site because I'm always up to date. So I'm not arguing for my personal taste. I just want all problems addressed. I can't understand how one can justify his choices in such an important redesign process with arguments like "because the present scheme fits our setup pretty well". Damn, you're working for everybody. > 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. Again, I'm sorry, but no way. This is like doing consciously something wrong first, and then reparing the damage afterwards. I'm not ready to make dozens of symlinks even if it's automatized in any fashion. Look, I don't think you've provided any concrete argument against mine yet: say we have here some share/ and lib/ directory. My share/ directory happens to be automounted on all machines. Not yours, perhaps you don't even have one. Now please, tell me /exactly/ how installing the packages, some part under share/, and some other under lib/ would break your setup ? What would it break appart from your personal taste ? I don't see how it could do any harm, but I see how it would simplify the life of many people. You know, I'm still open minded on this. We could find intermediate solutions. For example, it would be ok with me to have all stuff under /usr/local/xemacs, and then having /one/ share/ subdir under which all packages would put their sharable stuff. Doing one symlink, once for all, would be acceptable. But please, don't say things like "I won't change it". We're in the design phase. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released 25 years, 4 months

Michael Sperber

>>>>> "Colin" == Colin Rafferty <craffert(a)ms.com> writes: Colin> SL Baur writes: >> 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. Colin> Not just you. I've been getting this for a week: Colin> hobbes $ cvs update Colin> cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused Seems to me your cvs pserver port is wrong; it's 2401, not 2410. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: XEmacs 21.2.18 -- "$BK-Eg(B" is released 25 years, 4 months

Colin Rafferty

SL Baur writes: > 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. Not just you. I've been getting this for a week: hobbes $ cvs update cvs [update aborted]: connect to cvs.xemacs.org:2410 failed: Connection refused hobbes $ rtelnet cvs.xemacs.org Trying 208.25.65.6... Connected to cvs.xemacs.org. Escape character is '^]'. BSDI BSD/OS 3.0 (camelot-soft.camelot-soft.com) (ttyp0) login: q rtelnet> Connection closed. hobbes $ rtelnet cvs.xemacs.org 2410 Trying 208.25.65.6... telnet: Unable to connect to remote host: Connection refused hobbes $ -- Colin

1 participants
0 comments

Re: 21.2.18 failure 25 years, 4 months

ALTMARK＠de.ibm.com

Not exactly the same, but something similar: Loading select.el...Fatal error: assertion failed, file symbols.c, line 1783, abort() make: The signal code from the last command is 6. Stop. Compilation exited abnormally with code 2 at Wed Jul 14 15:03:12 This is AIX 4.3.2 and IBM xlC 3.6.4. --- Markus Alt IBM Laboratory Boeblingen, Germany sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) on 07/14/99 11:07:08 AM Please respond to sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) To: xemacs-beta(a)xemacs.org cc: (bcc: Markus Alt/Germany/IBM) Subject: 21.2.18 failure 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

Seg fault building 21.2 b18 on IRIX 6.2 25 years, 4 months

Paul Bibilo

I CVS updated everything and got the following build error: EMACSBOOTSTRAPLOADPATH="/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/:/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k" EMACSBOOTSTRAPMODULEPATH="/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../modules/:/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k" ./temacs -batch -l /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/update-elc.el Segmentation fault make[1]: *** [update-elc.stamp] Error 139 make[1]: Leaving directory `/devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src' make: *** [src] Error 1 You have mail in /usr/mail/peb dr2% gdb src/temacs GNU gdb 19990519 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mips-sgi-irix6.2"... (gdb) run -batch -l /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/update-elc.el Starting program: /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src/temacs -batch -l /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/../lisp/update-elc.el Program received signal SIGSEGV, Segmentation fault. strlen () at strlen.s:58 58 strlen.s: No such file or directory. Current language: auto; currently asm (gdb) bt #0 strlen () at strlen.s:58 #1 0x6ac134 in intern (str=0x0) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/symbols.c:585 #2 0x6b3f8c in defsubr (subr=0x100cd330) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/symbols.c:3404 #3 0x6933a4 in syms_of_select () at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/select.c:487 #4 0x4c3008 in xemacs_21_2_b18_mips_sgi_irix6_2 (argc=4, argv=0x7fff2f24, envp=0x7fff2f38, restart=0) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/emacs.c:2033 #5 0x4c4c74 in main (argc=4, argv=0x7fff2f24, envp=0x7fff2f38) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/emacs.c:2945 (gdb) quit The program is running. Exit anyway? (y or n) y -- Paul Bibilo, Delcam plc, | Tel: +44 121 766 5544 Talbot Way, Small Heath, Birmingham, | Fax: +44 121 766 5511 England, B10 0HJ. _____|_____ ICBM-mail: 52 17N 1 30W #include <disclaimer.h> | BLAT FOOP | ICQ: 32045109

1 participants
0 comments

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

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Yes... I missed the `why' part. Why was it taken out? > > Partly because noone could think of a good migration path. ..in the time available for 21.0. I think I have a good way to solve the custom issues, it needs implementing _and testing_. Jan

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