June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 21.1.x platform commitments 25 years, 5 months

Jason R Mastaler

Mike, Can you please direct followups to xemacs-binary-kits posts there and not to xemacs-beta? My reply to your questions is on xemacs-binary-kits. Thanks.

1 participants
0 comments

[Success] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i686-pc-cygwin 32 25 years, 5 months

Michael Hill

>From CVS with cygwin b19 workaround from Andy. > 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-b17 "Chiyoda" 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: [Failure] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i686-pc-cy gwin 32 25 years, 5 months

Michael Hill

Thanks Andy. This builds. > -----Original Message----- > From: Andy Piper [SMTP:andy＠xemacs.org] > Sent: Wednesday, June 30, 1999 7:53 AM > To: Mike Hill; 'xemacs-build-reports(a)xemacs.org'; > 'xemacs-beta(a)xemacs.org' > Subject: Re: [Failure] 21.2 (beta17) "Chiyoda" XEmacs Lucid on > i686-pc-cygwin 32 > > At 03:46 PM 6/29/99 -0400, Mike Hill wrote: > >From CVS again. Includes your fix of 1999-06-29, Andy. > > > >Now fails like this: > > > >gcc -c -O2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/local/include > >-Wno-sign-compare - > >fno-caller-saves -I/usr/X11R6.3/include event-msw.c > >event-msw.c:76: redefinition of `struct tagNMHDR' > >event-msw.c:80: warning: redefinition of `NMHDR' > >e:\\H-i386-cygwin32\lib\gcc-lib\i386-cygwin32\2.7-B19\../../../../i386-cy > gwi > >n32/ > > Sigh. So cygwinb19 is broken, but only half-broken. > > I have a fix I think. Try something like this: > > #if defined (__CYGWIN32__) && !defined (CYGWIN_VERSION_DLL_MAJOR) > typedef NMHDR *LPNMHDR; > #endif > > andy > -------------------------------------------------------------- > Dr Andy Piper > Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: GCC 2.95 good news 25 years, 5 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > I just build 21.1.3-latin-2 Hey! How did you do that? I've dreamed about doing that for ages! :-)

1 participants
0 comments

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

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Would it be difficult to have a separate "unsigned integer type?". > That could still go up to 2^30-1. That type would have to be an lrecord. Draw your own conclusion. > > That would be the worst possible option. Mule should bring new > > functionality, not cripple XEmacs. > > No released XEmacs has that functionality remember? 21.0 does. The very first item under "Lisp and internal changes" in its NEWS entry. > Note that currently you cripple anyway your XEmacs when you switch > it on, you get an enormous memory overhead on all lisp types. How does that cripple my XEmacs? It might cripple my system, but not XEmacs. The same way you could say that image support, variable width fonts, variable height lines and all that cruft "cripples" my XEmacs because of an "enormous memory overhead". > We have two competing primitive types. One of them is more or less > naturally limited to 31-bits and for the other the cut-off is > arbitrary. We have only one with 31-bits available, you choose? I choose integer. There must be other ways of dealing with chars. We've lived with 8-bit and 19-bit (19! what a number!) chars for quite a while. Surely a scheme can be devised for them to be thirty bit. No "scheme" will buy you 31-bit integers except the current one, and bignums. And bignums are hard. > > I can already hear people saying, "Oh, you need larger buffers? > > Why, compile without Mule -- everyone sensible does that." > > No, the answer would be "use a 64-bit system everyone sensible does > that". I constructed the hypothetical question and stand by the hypothetical answer. I'm sure people *do* think that way. Or do you think they will buy an alpha or ultrasparc rather than compile --without-mule? In your dreams! > I think the number of cases where you want to edit a 0.75 G file in > XEmacs is extremely low, certainly much lower than the # of people > profiting from full UCS-4 transparency (probably also not a big > group). Mule is the doom of us all, I can tell. > > > You do not really want to do O(n^2) operations on 1 Gbyte > > > buffers anyway. > > > > You don't. Why do you ask? > > Because I think editing a 1 Gbyte buffer in a Mule XEmacs will be so > slow that it doesn't matter much anyway. Have you tried it? I have tried 600M buffers, and things worked reasonably fast -- i.e. slow as hell, but workable in case of emergency. I still don't understand your remark about O(n^2) operations, though.

1 participants
0 comments

Re: Bad change to glyphs.c 25 years, 5 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > On Fri, Jun 25, 1999 at 05:10:43PM +0900, SL Baur wrote: > > This patch committed to 21.2 since b16 causes a non-X11 build to > > puke. Olivier? > > That's a missing #include <stddef.h> for offsetof. Is that portable?

4 participants
3 comments

GCC 2.95 good news 25 years, 5 months

Jan Vroonhof

I just build 21.1.3-latin-2 with the latest snapshot for GCC 2.95 on Sparc and so far there seem to be no problems. Jan

2 participants
1 comments

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

Jan Vroonhof

Before I start scaring you off: Would it be difficult to have a separate "unsigned integer type?". That could still go up to 2^30-1. Hrvoje Niksic <hniksic(a)srce.hr> writes: > That would be the worst possible option. Mule should bring new > functionality, not cripple XEmacs. No released XEmacs has that functionality remember? Note that currently you cripple anyway your XEmacs when you switch it on, you get an enormous memory overhead on all lisp types. I wouldn't loose any sleep over 1-bit of integer precision (unless we were going from 32 to 31). We have two competing primitive types. One of them is more or less naturally limited to 31-bits and for the other the cut-off is arbitrary. We have only one with 31-bits available, you choose? > I can already hear people saying, > "Oh, you need larger buffers? Why, compile without Mule -- everyone > sensible does that." No, the answer would be "use a 64-bit system everyone sensible does that". I think the number of cases where you want to edit a 0.75 G file in XEmacs is extremely low, certainly much lower than the # of people profiting from full UCS-4 transparency (probably also not a big group). > > You do not really want to do O(n^2) operations on 1 Gbyte buffers > > anyway. > > You don't. Why do you ask? Because I think editing a 1 Gbyte buffer in a Mule XEmacs will be so slow that it doesn't matter much anyway. Jan

1 participants
0 comments

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

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > The appended patch swaps the Lisp integer with the Lisp character > representations, so that characters have 31 bits of precision. This > allows Lisp characters to represent the entire UCS-4 code space. I > don't see that loss of one bit of precision in integers hurts; where > it matters (time values, etc) we need 32 bits anyway, and classical > Emacsen didn't have even 30 bits. As Kyle noticed, buffer sizes will suffer. Currently an Emacs buffer can accept up to 1G of characters. With the swap, it will be "only" 512M. Believe it or not, there _will_ be people hurt by the difference. That the classical Emacsen didn't even have 30 bits is not a good argument. I've written a NEWS entry that says: ** It is now possible to build XEmacs with support for 31-bit Lisp integers (normally, Lisp integers are only 28 bits wide on 32-bit machines.) Configure with --use-minimal-tagbits to test. With this change, the maximum buffer size on 32-bit machines is increased from 128M to 1G. This setting will be made default in a future XEmacs version. I wouldn't like to lose this. Finally, I do need integers as large as I can get, even when it's not the full 32 bits. We'll have to find another way for dealing with UCS-4.

3 participants
2 comments

[Failure] 21.2 (beta17) "Chiyoda" XEmacs Lucid on i686-pc-cygwin 32 25 years, 5 months

Michael Hill

>From CVS again. Includes your fix of 1999-06-29, Andy. Now fails like this: gcc -c -O2 -Demacs -I. -DHAVE_CONFIG_H -I/usr/local/include -Wno-sign-compare - fno-caller-saves -I/usr/X11R6.3/include event-msw.c event-msw.c:76: redefinition of `struct tagNMHDR' event-msw.c:80: warning: redefinition of `NMHDR' e:\\H-i386-cygwin32\lib\gcc-lib\i386-cygwin32\2.7-B19\../../../../i386-cygwi n32/ include/Windows32/Structures.h:1999: warning: `NMHDR' previously declared here make[1]: *** [event-msw.o] Error 1 make: *** [dump-elcs] Error 2 uname -a: CYGWIN32_NT DILBERT 4.0 19.4 i686 unknown ./configure '--package-path=/binary/xemacs-20' '--site-includes=/usr/local/incl ude' '--cflags=-O2' XEmacs 21.2-b17 "Chiyoda" 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: ---------------------------------------------------------

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