November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

XEmacs and ncurses 4.x 25 years, 5 months

Christian Kurz

Hi i've just recompiled XEmacs using ncurses 4.x. Now he is running well and I had no crash since the compilation, but while compiling he complained about the missing ncurses 3.x. So now my questions is, are you going to make XEmacs work with the new ncurses or not? If XEmacs already compiles with ncurses well, I would be happy if you tell me the version number. Christian -- M$: Our software of tomorrow will make sure that on your hardware of tomorrow everything will work at the usual speed. ;-)

1 participants
0 comments

Re: Is 21.x going to be 64-bit clean? 25 years, 5 months

Charles Stephens

>>>>> "HN" == Hrvoje Niksic <hniksic(a)srce.hr> writes: HN> Hrvoje Niksic <hniksic(a)srce.hr> writes: >> Martin Buchholz <martin(a)xemacs.org> writes: >> >> > Georg Nikodym <georgn(a)Canada.Sun.COM> is the authority on getting >> > dumping to work on Suns, and has a successful build of XEmacs on >> > Solaris Bleeding-Edge Operating Environment. >> >> Does that include LP64 environment? HN> To make it clear: I assume that XEmacs compiles under Solaris 7 32-bit HN> environment. However, Charles had problems compiling XEmacs as a HN> 64-bit application, and I'm not sure Georg tested that. Georg, does HN> XEmacs work in LP64 for you? Yes, XEmacs does compile as a 32-bit application just fine. As a 64-bit application, it compiles (after some electroshock therapy: 64-bit libaudio, compiling other support libraries for 64-bits, etc.) however it hangs at the following point of the make (this is a 20.4 example, but the same occurs with 21.x): EMACSLOADPATH="/public/Users/cfs/Build/xemacs-20.4/src/../lisp/prim" ./temacs -batch -l ../prim/update-elc.el Loading ../prim/update-elc.el... Loading /public/Users/cfs/Build/xemacs-20.4/src/../lisp/prim/dumped-lisp.el... temacs does not do any system calls, it just spins eating 100% of the CPU. Admittingly I am not an XEmacs wizard, but I need to buy a clue. Thanks for everyone is helping me on this difficult path to 64-bit purity. :) cfs -- Charles F. Stephens = cfs AT eng.sun.com Software Psychic and Illuminary = Solaris Network Sustaining = "We know what you buy, we know where you Solaris Software = live." -- Wesayso Corp. Sun Microsystems, Inc. = Menlo Park, California, USA =

1 participants
0 comments

Re: Is 21.x going to be 64-bit clean? 25 years, 5 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > Georg Nikodym <georgn(a)Canada.Sun.COM> is the authority on getting > dumping to work on Suns, and has a successful build of XEmacs on > Solaris Bleeding-Edge Operating Environment. Does that include LP64 environment? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Nostalgia isn't what it used to be.

1 participants
0 comments

Re: Is 21.x going to be 64-bit clean? 25 years, 5 months

Olivier Galibert

On Mon, Nov 02, 1998 at 01:35:59PM -0800, Charles Stephens wrote: > > I seem to have problems compiling XEmacs 21 (or 20.4 for that matter) > on SunOS 5.7 with the 64-bit compiler. > > It seems that in several places in the code, XEmacs makes assumptions > about the size of int's and long's and it assumes they are same size. No it doesn't. It compiles out of the box on alpha and on irix 6.x in 64bits mode. I tracked and killed a bunch of 64bits related bugs, and I have seen no related bug report for a while (which does not mean I caught them all, of course). > Here is an example from lisp.h: > > #if (LONGBITS > INTBITS) > # define EMACS_INT long > # define EMACS_UINT unsigned long > # define SIZEOF_EMACS_INT SIZEOF_LONG > #else# define EMACS_INT int > # define EMACS_UINT unsigned int > # define SIZEOF_EMACS_INT SIZEOF_INT > #endif This means "an EMACS_INT is the biggest on int and long", i.e. a 32bits integer on 32bits architectures and a 64bits one elsewhere. > #if (LONGBITS < 16) > #error What the hell?! > #elif (LONGBITS < 32) > # define LONGBITS_LOG2 4 > # define LONGBITS_POWER_OF_2 16 > #elif (LONGBITS < 64) > # define LONGBITS_LOG2 5 > # define LONGBITS_POWER_OF_2 32 > #elif (LONGBITS < 128) > # define LONGBITS_LOG2 6 > # define LONGBITS_POWER_OF_2 64 > #else > #error You really have 128-bit integers?!#endif > > INLINE int > bit_vector_bit (struct Lisp_Bit_Vector *v, int i) > { > unsigned int ui = (unsigned int) i; > > return (((v)->bits[ui >> LONGBITS_LOG2] >> (ui & (LONGBITS_POWER_OF_2 - 1))) > & 1); > } While Lisp_Bit_Vector::bits is declared as an int array for alignment purposes, which is arguably a bug but not a real problem (because of the long size preceding it, and the alignment requirements of sizeof), they really are allocated as longs. This code is correct, and I'm sending a patch for the declaration. > The end result is that temacs goes off to visit Elvis when it is > trying to do the dynodump. Dynodump, being sun specific, has afaik never been tested on a 64bits architecture. The problem probably lies there. I don't think anybody here has the required hardware to fix it, so all I can say is good luck. But you can trust the common code for 64bits cleanliness. OG.

2 participants
2 comments

Re: Is 21.x going to be 64-bit clean? 25 years, 5 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > > The end result is that temacs goes off to visit Elvis when it is > > trying to do the dynodump. > > Dynodump, being sun specific, has afaik never been tested on a > 64bits architecture. And will probably never be, since it should not be needed on Solaris 2.7 and further. We use dldump() instead. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- * Q: What is an experienced Emacs user? * A: A person who wishes that the terminal had pedals.

1 participants
0 comments

Is 21.x going to be 64-bit clean? 25 years, 6 months

Charles Stephens

I seem to have problems compiling XEmacs 21 (or 20.4 for that matter) on SunOS 5.7 with the 64-bit compiler. It seems that in several places in the code, XEmacs makes assumptions about the size of int's and long's and it assumes they are same size. Here is an example from lisp.h: #if (LONGBITS > INTBITS) # define EMACS_INT long # define EMACS_UINT unsigned long # define SIZEOF_EMACS_INT SIZEOF_LONG #else# define EMACS_INT int # define EMACS_UINT unsigned int # define SIZEOF_EMACS_INT SIZEOF_INT #endif ... #if (LONGBITS < 16) #error What the hell?! #elif (LONGBITS < 32) # define LONGBITS_LOG2 4 # define LONGBITS_POWER_OF_2 16 #elif (LONGBITS < 64) # define LONGBITS_LOG2 5 # define LONGBITS_POWER_OF_2 32 #elif (LONGBITS < 128) # define LONGBITS_LOG2 6 # define LONGBITS_POWER_OF_2 64 #else #error You really have 128-bit integers?!#endif INLINE int bit_vector_bit (struct Lisp_Bit_Vector *v, int i) { unsigned int ui = (unsigned int) i; return (((v)->bits[ui >> LONGBITS_LOG2] >> (ui & (LONGBITS_POWER_OF_2 - 1))) & 1); } The end result is that temacs goes off to visit Elvis when it is trying to do the dynodump. How is this done on 64-bit only arch. like Alpha? cfs -- Charles F. Stephens = cfs AT eng.sun.com Software Psychic and Illuminary = Solaris Network Sustaining = "We know what you buy, we know where you Solaris Software = live." -- Wesayso Corp. Sun Microsystems, Inc. = Menlo Park, California, USA =

1 participants
0 comments

b57 core dump 25 years, 6 months

Neal D. Becker

I did find-file and got a dump: #0 0x403376a1 in ?? () from /lib/libc.so.6 (gdb) where #0 0x403376a1 in ?? () from /lib/libc.so.6 #1 0xbffff26c in ?? () #2 0x8154545 in Fset_window_buffer (window=153395800, buffer=152453272) at window.c:3169 #3 0x80a1bda in funcall_recording_as (recorded_as=137013004, nargs=2, args=0xbffff4a0) at eval.c:3197 #4 0x80a5cc7 in Ffuncall (nargs=3, args=0xbffff4a0) at eval.c:3238 #5 0x8083d06 in Fbyte_code (bytestr=136405992, vector=136406140, maxdepth=9) at bytecode.c:416 #6 0x80a2902 in funcall_lambda (fun=136406348, nargs=1, arg_vector=0xbffff654) at eval.c:3597 #7 0x80a1d34 in funcall_recording_as (recorded_as=136966016, nargs=1, args=0xbffff650) at eval.c:3214 #8 0x80a5cc7 in Ffuncall (nargs=2, args=0xbffff650) at eval.c:3238 #9 0x8083d06 in Fbyte_code (bytestr=136325488, vector=136325576, maxdepth=7) at bytecode.c:416 #10 0x80a2902 in funcall_lambda (fun=136325616, nargs=2, arg_vector=0xbffff7b4) at eval.c:3597 #11 0x80a1d34 in funcall_recording_as (recorded_as=137381772, nargs=2, args=0xbffff7b0) at eval.c:3214 #12 0x80a5cc7 in Ffuncall (nargs=3, args=0xbffff7b0) at eval.c:3238 #13 0x8086732 in Fcall_interactively (function=137381772, record_flag=136894148, keys=136894148) at callint.c:949 #14 0x80a090d in Fcommand_execute (cmd=137381772, record=136894148, keys=136894148) at eval.c:2584 #15 0x80c393a in execute_command_event (command_builder=0x82e5848, event=139608684) at event-stream.c:4346 #16 0x80c4096 in Fdispatch_event (event=139608684) at event-stream.c:4685 #17 0x808a15c in Fcommand_loop_1 () at cmdloop.c:579 #18 0x808a322 in command_loop_1 (dummy=136894148) at cmdloop.c:494 #19 0x80a597f in condition_case_1 (handlers=136894260, bfun=0x808a30c <command_loop_1>, barg=136894148, hfun=0x8089c40 <cmd_error>, harg=136894148) at eval.c:1653 #20 0x808a3fc in command_loop_2 (dummy=136894148) at cmdloop.c:256 #21 0x80a585b in internal_catch (tag=136968520, func=0x808a3c8 <command_loop_2>, arg=136894148, threw=0x0) at eval.c:1328 #22 0x8089e8c in initial_command_loop (load_me=136894148) at cmdloop.c:305 #23 0x809d231 in xemacs_21_0_i686_pc_linux () at emacs.c:1705 #24 0x809e781 in main (argc=1, argv=0xbffffc84, envp=0xbffffc8c) at emacs.c:2122

2 participants
1 comments

xemacs 21.0 on alpha-linux 25 years, 6 months

Falk Hueffner

Hi, I tried to compile the latest xemacs 21.0 beta on an Alpha 164Sx with Linux. The compile went fine, but the resulting temacs insisted "temacs can only be run in batch mode", although it was clearly called with -batch. I used egcs 2.91.57, binutils 2.9.1.0.15 and glibc 2.0.7u. Does anybody know what to do or how I could find the error? Falk Hueffner

1 participants
0 comments

Bugs in 21.2 Beta 3 25 years, 6 months

Heiko Münkel

XEmacs: 21.2 beta 3 System: Linux 2.0.32 i586 1. Bug: There's a bug in the function `pui-install-selected-packages'. Wrong arguments are given to `package-get'. The following patch fixes that. It adds also some usefull comments to the variable `pui-package-install-dest-dir'. In my mind this variable should have a usefull default, even if you've no packages installed. --- package-ui.el.~1~ Mon Nov 2 10:15:29 1998 +++ package-ui.el Mon Nov 2 10:31:16 1998 ＠＠ -39,7 +39,10 ＠＠ (defcustom pui-package-install-dest-dir nil "*If non-nil (Automatic) path to package tree to install packages in. Otherwise, use old path for installed packages and make a guess for -new ones." +new ones. + +ATTENTION: The path must have a trailing slash (on UNIX systems) and + it must be listed in `package-locations'!" :group 'pui :tag "Install Location" :type '(choice (const :tag "Automatic" nil) ＠＠ -332,7 +335,7 ＠＠ (message "Installing selected packages ...") (sit-for 0) (if (catch 'done (mapcar (lambda (pkg) - (if (not (package-get pkg + (if (not (package-get pkg nil nil pui-package-install-dest-dir)) (throw 'done nil))) pui-selected-packages) 2. Bug: There's a bug in isearch. If you search with C-s in a buffer with the `fundamental-mode' and exit the search by hitting C-a, C-b or something similar, the isearch highlighting won't be gone. In these situations, the isearch command seems to be in a mysterious state. 3. Bug: The vm toolbar (it's on the left side of my frame) will be broken (partly or total invisible), if you use bbdb and convert an old bbdb database to version 3 during the loading of vm. 4. Bug: Installed sound packages are shown as uninstalled in the package list produced by `pui-list-packages'. May be, that this is caused by the fact, that the sound packages have no lisp files and therefore no _pkg.el. 5. Bug (Minor): The command `pui-list-packages' won't work, if you've no internet access (no access to a package source directory). In my mind it should display the list of installed packages and/or a hint, that an update isn't possible, because there's no access to a package source directory. 6. Bug: I've got the following message in the xterm, where I've started the XEmacs: Comparison between integer and character is constant nil (50 and ?m) [ispell-command-loop, byte-code, <compiled-function of unknown origin>, call-interactively] I'm sorry, but I don't know how to reproduce this message. Regards, Heiko

1 participants
0 comments

Re: please add package: greedy-delete 25 years, 6 months

Greg Klanderman

It seems to work just fine for me. I 'm using it for C, elisp, and perl, and should probably enable for a few other modes. CC-mode of course has it's own version but I use GD for consistency and because I hadn't previously been using cc-mode's version. I've got this in my .emacs (require 'greedy-delete) (setq gd-how-much 'line) ; 'line or 'all (defun gk:gd-delete-at-bol-only () ; only do gd when in indentation (save-excursion (skip-chars-backward " \t") (bolp))) (setq-default gd-mode-check-function 'gk:gd-delete-at-bol-only) (setq gd-indicator-string " GD") (foreach '(c-mode-common-hook ; install for programming modes emacs-lisp-mode-hook perl-mode-hook cperl-mode-hook) (lambda (hook) (add-hook hook 'gd-add-to-mode))) >>>>> "BAW" == Barry A Warsaw <bwarsaw(a)cnri.reston.va.us> writes: BAW> ... BAW> Greg, if you or anyone else is using greedy-delete.el and have some BAW> feedback on it, I'd love to hear it (where are you using it, etc?). BAW> Steve, given that description, I leave it up to you :-) ...

2 participants
1 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 November 1998