April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

RE: FW: [Failure] 21.0 "Repartida-pre2" XEmacs Lucid (beta38) on 25 years, 12 months

Ian MacKinnon

Yes, in /bin the sh is a copy of bash, but my path has the cygwin bin first, and that is sh (if you can follow that) --- Ian -----Original Message----- From: david.bush(a)adn.alcatel.com [mailto:david.bush＠adn.alcatel.com] Sent: Thursday, April 30, 1998 2:18 PM To: IMacKinnon(a)telia.co.uk Cc: xemacs-beta(a)xemacs.org Subject: Re: FW: [Failure] 21.0 "Repartida-pre2" XEmacs Lucid (beta38) on I just encountered the same problem. My solution was to reset my path to PATH=/bin/sh:$PATH. I believe the reason is that I have the updated (a)sh form Chris Faylor in /bin/sh but the original sh in the cygwin bin directory. david

1 participants
0 comments

Re: giflib, what version and WHERE? 25 years, 12 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > > Why don't you release a giflib lite that knows only how to read GIFs, > > not write them? Then you could wash your hands off the full version, > > until the dust settles. > > I don't believe that resolves the patent problem. I thought only the compression (i.e. GIF creation) was patented? > I also don't think it would matter if a copy of giflib got magically > posted on Usenet via an anonymous remailer. Oh. :-( > Maybe now _is_ a good time to convert all our GIFs to PNGs. The > (potential) lack of GIF support is going to hurt W3 though. Yup. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

1 participants
0 comments

widget active/inactive problems 25 years, 12 months

Adrian Aichner

Hello Hrvoje, I have played with widget activation/deactivation a bit. Here is what I found: push-buttons appear inactive after being re-activated until any push-button is pushed again. Can you reproduce this bug? In tty-mode there is no visual distinction between active and inactive widgets. I don't know whether the interface can be improved to provide this feedback on tty. What are your thoughts on this? Here is a testcase which I derived from the widget-example in the info docs for Widget under emacs-version "21.0 \"Pygmy\" XEmacs Lucid (beta37)". Regards, Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Straße 2 Fax +49/89/41861-217 D-81673 MÜNCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: Plea for minimal tagbits 25 years, 12 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > On Thu, Apr 30, 1998 at 02:31:27AM +0200, Hrvoje Niksic wrote: > > I don't think minimal tagbits should be default, because I don't see > > any good reasons to make them so before the new dumper is written. > > *mumble*. I'm going to go and write it if it continues that way. Please do! You'll be our hero. :-) > > Yes, performance is equivalent (although I don't remember any actual > > study), but memory usage is not. Minimal tagbits consume more memory > > for conses. This will be fixed by Kyle's dumper, which will not dump > > free lists. > > Do you mean "lists the garbage collector freed but for which free() > didn't give the memory bakc to the system" ? Yup. I am referring to some tests run by Kyle. She tried to estimate how much more memory XEmacs spends with minimal tagbits (it spends more memory because conses are lrecords, thus requiring an lrecord_header per each cons struct), and counted additional 400K of memory in a new XEmacs. However, most of that memory came from the free lists which the old dumper dumped with the temacs executable. > > > 31-bit integers are nice, but they are hardly that important to a > > normal user. Even so, the configure option is documented in NEWS, so > > the interesting parties will be able to test it. > > I just remembered a thing. (point) being a integer, it limits the > maximum size of a buffer to 8Mb, right ? Wrong. More like 128M. The 8M problem has been solved a long time ago. And while I accede that 1G is better than 128M, 128M is reasonable too. > > Removing the old code is an even worse idea. While I personally > > prefer the code with less #ifdef's, being able to run regression tests > > is *crucial*. With the new dumper in place, it will be even more > > important for tracking dumper bugs. > > What prevents from running regression tests ? If you remove the old code, there is no more "let's compile this with maximal tagbits and see if the bug repeats." Currently we can do that easily. -- 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

Re: Plea for minimal tagbits 25 years, 12 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> 31-bit integers are nice, but they are hardly that > Hrvoje> important to a normal user. > > But when Olivier gets his UCS-4 text manipulation stuff working.... ??? Stephen, remember that we are talking about XEmacs 21 and the next code freeze. So many people are now using minimal tagbits that it will be quite easy to change the default when the time is ripe. If a Good Reason (tm) for defaulting minimal-tagbits comes, I'll be all for them. Examples of Good Reasons are Kyle's new dumper and Olivier's UCS-4 text manipulation. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Try to use "ad nauseam" at least once per flame. It doesn't mean anything; but it gives that polished feel to your postings.

1 participants
0 comments

Re: Plea for minimal tagbits 25 years, 12 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > In a 64-bit world, we might want to EXPAND the tagbits and keep > enough type bits to represent all the lisp types. Uh, not really. First, it would undermine the new dumper. Second, I don't think it's a good idea to actually make MAXLISP *smaller*, even on 64-bit machines. So before expanding tag bits, we should think about the ramifications... -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Then... his face does a complete change of expression. It goes from a "Vengeance is mine" expression, to a "What the fuck" blank look.

1 participants
0 comments

[Success] XEmacs 21.0-b38 "Repartida-pre2" on i686-linux 25 years, 12 months

Nobu Toge

Builds and runs fine, with mule/canna, including the tty mode. The compiler is egcs 1.02. BTW, gnus in the X-window mode barks at me unless I also install w3. The reason is that gnus wants images.el which is part of w3. I guess there are cases where the user wants to use gnus but not w3. Can images.el be part of xemacs-base or something, or am I too picky? ----- uname -a: Linux lcdev.kek.jp 2.0.33 #1 Wed Apr 29 21:39:30 JST 1998 i686 unknown ./configure 'i686-GNU-linux' '--with-gnu-make' '--with-mule' '--with-canna' '--dyn amic=yes' '--debug=no' '--error-checking=malloc' '--cflags=-g -O2 -m486 -fno-streng th-reduce -malign-loops=2 -malign-jumps=2 -malign-functions=2 -fno-caller-saves' '- -use-union-type' '--error-checking=malloc' '--with-site-lisp' '--package-path=/usr/ local/lib/xemacspack' XEmacs 21.0-b38 "Repartida-pre2" configured for `i686-GNU-linux'. Where should the build process find the source code? /home/toge/NONRH/XEmacs21 .0/xemacs-21.0-b36 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O2 -m486 -fno-str ength-reduce -malign-loops=2 -malign-jumps=2 -malign-functions=2 -fno-caller-saves Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the Linux C Library.) 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/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for OffiX. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using the union type for Lisp_Objects. Using Lisp_Objects with minimal tagbits. 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: --------------------------------------------------------- -- Nobu Toge (toge(a)accad1.kek.jp)

1 participants
0 comments

RE: FW: [Failure] 21.0 "Repartida-pre2" XEmacs Lucid (beta38) on i38 6-pc-cygwin32 25 years, 12 months

Ian MacKinnon

I think this may be my config of the cygwin. In the top level makefile there is a line calling a shell script to compile the elc's. The calling of this script was failing. If I called it with /bin/sh instead of sh all was fine I will look further into why it was failing --- Ian -----Original Message----- From: SL Baur [mailto:steve＠xemacs.org] Sent: Thursday, April 30, 1998 11:44 AM To: xemacs-beta(a)xemacs.org Subject: Re: FW: [Failure] 21.0 "Repartida-pre2" XEmacs Lucid (beta38) on i38 6-pc-cygwin32 Ian MacKinnon <IMacKinnon(a)telia.co.uk> writes: > Aha! If I put /bin in front of the sh in the makefile all is well Eh?

2 participants
1 comments

[Success] XEmacs 21.0-b38 "Repartida-pre2" on HPUX 9.05 25 years, 12 months

Nobu Toge

Repartida-pre2. Build and running all fine on HPUX 9.05, with mule/canna, including tty mode. The compiler is gcc 2.8.1. uname -a: HP-UX accad1 A.09.05 A 9000/735 2005266055 two-user license ./configure 'hppa1.1-hp-hpux9.05' '--dynamic=yes' '--prefix=/usr/local' '--with-dialogs=athena' '--with-xface' '--with-tty=yes' '--site-includes=/usr/local/lib/gcc-lib/hppa1.1-hp-hpux9.05/2.8.1/include /usr/local/canna/include' '--error-checking=none' '--with-jpeg' '--with-xpm' '--with-sound=no' '--with-mule' '--with-canna' '--with-xfs' '--with-database=no' '--with-x' '--cflags=-pipe -mpa-risc-1-1 -mschedule=7100 -mjump-in-delay -funroll-loops -O5' '--package-path=/usr/local/lib/xemacspack' XEmacs 21.0-b38 "Repartida-pre2" configured for `hppa1.1-hp-hpux9.05'. Where should the build process find the source code? /users4/toge/HPUX/XEmacs210/xemacs-21.0-b36 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/hpux9-shr.h' and `m/hp800.h' What compiler should XEmacs be built with? gcc -pipe -mpa-risc-1-1 -mschedule=7100 -mjump-in-delay -funroll-loops -O5 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/include/Motif1.2 /usr/local/X11R6/include Where do we find X Windows libraries? /usr/lib/Motif1.2 /usr/lib/X11R6 Additional header files: /usr/local/lib/gcc-lib/hppa1.1-hp-hpux9.05/2.8.1/include /usr/local/canna/include Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for OffiX. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. -- Nobu Toge (toge(a)accad1.kek.jp)

1 participants
0 comments

[OK] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 25 years, 12 months

Carsten Leonhardt

Maybe a bit late, but nonetheless. I only got caught by not having installed the new fsf-compat package, which was easily resolved. compiled with egcs 1.0.2 xemacs-base is v1.18 efs is v1.08

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