August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

SL Baur

Kenichi Okuyama <okuyama(a)trl.ibm.co.jp> writes in xemacs-beta(a)xemacs.org: >>>>>> "SJ" == Simon Josefsson <jas(a)pdc.kth.se> writes: >>> Build 21.0 betas with `--with-minimal-tagbits'. It raises the 28-bit >>> limit to 31-bit. There's more to it than that. It also moves the tagbit from the topmost bit to the lower most bit. This will work fine so long as malloc() returns memory that is aligned to at least 32 bit boundaries. SJ> We're getting somewhere. :-) > I would like to say that "Even 31 bit is not enough". > As all of you in this ML know, emacs allocates cons-cells and other > "tiny" resources by chunk of 1k using malloc. But if we can make > this size to 4k, and use "mmap()" system call, on some machine, it > will increase Virtual Memory usage, which will lessen the swap IO > and make entire system works faster. We do this already. With the old GNU malloc in XEmacs, the mmapping version of the relocating allocator can be used. The new GNU malloc (Doug Lea malloc) in Linux libc5 and GNU libc uses mmapping for allocation under certain conditions. Note that FSF Emacs 20.2 can use the Doug Lea malloc, but it unconditionally turns off usage of mmap. I haven't checked 20.3 to see if they fixed that. > (all we need to do is use PHKmalloc instead of GNU-malloc and change > constant from 1024 to 4096) What is PHKmalloc? If it's portable and faster, I have no problem replacing the old GNU malloc with it, or adding it as an additional option. > But, for AIX, mmap() will map the new page to address higher then > 0x80000000, which means we need 32nd bit. I'm pretty sure that even > on some other OS have same kind of limitation. Yup. DL malloc does that too. Fortunately Kyle has already fixed the XEmacs internals so that the tagbits are on the low side so all of the high bits are usable in pointer addresses. ... > So this is what I want to say: > "We need entire addressing space. If you have any Idea on > putting new information into address bit field, please don't. > We need entire addressing space for addressing." We have the entire addressing space with 32 bit alignment. We don't have more than 31 bits available for integers.

2 participants
1 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > a) Add them as another datatype comletely separate from Elisp fixnums, > with explicit coercions back and forth. > > This, I believe, is possible with minimal changes to the Elisp > machine, even though it's still a sufficiently hairy job, 'cause > you need to interface with the garbage collector in a suitable > way. Not hairy at all. Have you looked at DEFINE_LRECORD_IMPLEMENTATION? It allows you to specify a callback routine for the GC. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- We are all just prisoners here of our own MAKEDEV.

1 participants
0 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Hrvoje Niksic

Simon Josefsson <jas(a)pdc.kth.se> writes: > I wasn't thinking about adding a elisp type for bignums (I guess this > is what you're refeering to?) but instead have the MP-routines use a > internal representation (a vector containg bytes or something) and > have a function like gmp-print for printing the numbers as a string. > > GMP works like this in C so this would be the most natural solution. Yuck! This is *far* from natural for me, because bignums have a tradition of being correctly implemented in various Lisps. We should either do it correctly, or not do it at all, as far as I'm concerned. But now at least I understand what you mean, and I agree that "implementing" bignums using an external library would not be a big deal. It even might be doable in the form of a loadable module. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray, on virtual memory

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 3 months

Hrvoje Niksic

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > Hrvoje> Used books are cheaper, but it's hard to find a used book > Hrvoje> about programming, especially about something as exotic as > Hrvoje> Lisp or Scheme. > > I wonder if it's too expensive to order them from the USA, and have > them shipped to you? I think it would boil down to the same price, unless there is a way to reduce the shipping cost. Also, without a credit card, online shopping is very tedious. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.

1 participants
0 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Simon Josefsson

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I'm surprised that you all seem to miss it, but bignums cannot be > added as a module, because they require additional support in the > Lisp engine, as well as changes all over XEmacs. I wasn't thinking about adding a elisp type for bignums (I guess this is what you're refeering to?) but instead have the MP-routines use a internal representation (a vector containg bytes or something) and have a function like gmp-print for printing the numbers as a string. GMP works like this in C so this would be the most natural solution. /s

1 participants
0 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> SL Baur <steve(a)xemacs.org> writes: >> Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: >> >> > I'm surprised that you all seem to miss it, but bignums cannot be >> > added as a module, because they require additional support in the Lisp >> > engine, as well as changes all over XEmacs. >> >> We're not talking about bignum support as it exists in CL. We're only >> talking about how large integers can be supported period.[1] Hrvoje> I don't understand this distinction. Obviously, 31(63)-bit integers Hrvoje> are the most we can do with the fixnums. To support larger numbers, Hrvoje> we need a) a library of routines to deal with the numbers, and b) the Hrvoje> changes in Emacs Lisp to support them. There are two basic approaches to supporting bignums in Elisp: a) Add them as another datatype comletely separate from Elisp fixnums, with explicit coercions back and forth. This, I believe, is possible with minimal changes to the Elisp machine, even though it's still a sufficiently hairy job, 'cause you need to interface with the garbage collector in a suitable way. b) Unify fixnums and bignums so that the difference is no longer visible from Elisp, i.e. with automatic conversions back and forth and so on. This is a much more involved change, because all arithmetic operations need to be changed, parsing/unparsing of literals needs to be reimplemented and so on and on. This (hate to say it ...) may be better left to a new Lisp engine. On the other hand, (a) may be entirely sufficient to implement crypto stuff. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: X-error in get_mouse_position 26 years, 3 months

Hrvoje Niksic

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > Martin suggested WINDOW_LIVE_P from window.h but unless I am > mistaken this refers to XEmacs windows and not XWindows Windows > (mind the capital W). Aren't there functions and macros that map from Emacs windows to X Windows and vice versa? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- By any chance, have you seen a summoned 9th order fire elemental wandering around? No? Oh.. Tell me if you do.

1 participants
0 comments

[Success] 21.0 "Erzgeberg" XEmacs Lucid on i686-pc-cygwin32 26 years, 3 months

Michael Hill

Patched up from b52, with Hrvoje's other file-readable-p patch and Andy's new local dist. > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /binary/xemacs-21.0-b52/Installation: > (Output from most recent run of ./configure) uname -a: CYGWIN32_NT DILBERT 4.0 19.1 i686 unknown ./configure '--site-includes=/usr/local/include' XEmacs 21.0 "Erzgeberg" configured for `i686-pc-cygwin32'. Where should the build process find the source code? /binary/xemacs-21.0-b52 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 -g -O2 -Wall -Wno-switch 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 File coding support. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. > /binary/xemacs-21.0-b52/beta.err does not exist!

1 participants
0 comments

Re: 28 bit ought to be enough for anyone. 26 years, 3 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > > I'm surprised that you all seem to miss it, but bignums cannot be > > added as a module, because they require additional support in the Lisp > > engine, as well as changes all over XEmacs. > > We're not talking about bignum support as it exists in CL. We're only > talking about how large integers can be supported period.[1] I don't understand this distinction. Obviously, 31(63)-bit integers are the most we can do with the fixnums. To support larger numbers, we need a) a library of routines to deal with the numbers, and b) the changes in Emacs Lisp to support them. > If we are talking about bignum support, then you are correct. I don't see what else we could be talking about, given the context of the thread. > In terms of getting support from a DLL that links against GMP and uses > an opaque LRECORD object, I think it should be possible, though I > don't know whether it is possible. Oh, I think I see what you mean now. Supporting bignums that way is too broken for me to consider it. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Psychos _do not_ explode when sunlight hits them."

1 participants
0 comments

Re: X-error in get_mouse_position 26 years, 3 months

Gunnar Evermann

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > evaluating the following results in an X Error on stderr. (Linux > 2.0.35, Xfree86 3.3.2, fvwm2). > > (progn > (setq f (make-frame)) > (delete-frame f) > (mouse-position)) > > xemacs: X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 40 (X_TranslateCoords) > Resource id in failed request: 0x8002cf > Serial number of failed request: 1455 > Current serial number in output stream: 1455 [blahblah snipped] > > --- frame-x.c.orig Sat Jun 13 06:28:48 1998 > +++ frame-x.c Sat Aug 15 23:47:11 1998 > ＠＠ -2371,6 +2371,8 ＠＠ > unsigned int keys_and_buttons; > struct frame *f; > > + XSync(display, False); > + > if (XQueryPointer (display, RootWindow (display, DefaultScreen (display)), > &root_window, &child_window, &root_x, &root_y, > &win_x, &win_y, &keys_and_buttons) == False) Ok, since Martin vetoed this patch (for good reasons) and nobody else reacted, I need to find a different solution. A (marginally) closer inspection reveals that XQueryPointer returns a child_window, which produces the 'Bad Window' on the subsequent XTranslateCoordinates call. I guess this Window corresponds to the frame just deleted (the control frame in ediff). Is there a way to test whether a Window will result in a 'Bad Window'-error?? Martin suggested WINDOW_LIVE_P from window.h but unless I am mistaken this refers to XEmacs windows and not XWindows Windows (mind the capital W). Any ideas? Or suggestions for a good intro book to X? Currently I only have the man-pages :-( Gunnar -- Gunnar Evermann Natural Language Systems Group, University of Hamburg EMail: Gunnar.Evermann(a)nats.informatik.uni-hamburg.de

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