November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Out of toppic: The Halloween Documents 25 years, 5 months

William M. Perry

Heiko Muenkel <muenkel(a)tnt.uni-hannover.de> writes: > I think everyone, who writes free software should read the so called > Halloween Documents on http://www.opensource.org/halloween.html and > should be aware, that he is a major enemie of `Billie Boy' and therefore > must be bought or destroyed ... also check out http://www.microsoft.com/ntserver/highlights/editorletter.asp for their response. Seems reasonable enough, other than the bit about open standards at the end. :) I've met Vinod a few times and he is a pretty sharp guy, but definitely steeped in the microsoft way. -Bill P.

1 participants
0 comments

Re: vfork revisited (was 64bit clean XEmacs) 25 years, 5 months

Holger Schauer

>>>>"GC" == Glynn Clements schrieb am Thu, 5 Nov 1998 19:32:27 +0000 (GMT): GC> But you can't know that this will be the case at the time that GC> fork() was called; the child might not call exec(). GC> If you get around the problem by overcommitting, then you are GC> left with a child process which can die suddenly just because it GC> wrote to one page too many. This isn't a good idea if you want to GC> write robust programs. This is exactly the situation on Linux 2.0.* (don't know for sure about 2.1.*), if I read the current discussion on the (german) de.comp.os.unix.discussion. GC> The solution is to provide a usable vfork(), i.e. one where you GC> can guarantee being able to perform a minimal set of useful GC> operations between the vfork() and the exec(). dup2() is an GC> obvious candidate; signal handling would also be pretty high on GC> the list. I would like to get more information on that idea (and on dup2), could you provide some (perhaps by private email) for reproduction in that current discussion. Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch." -- Anselm Lingnau in de.comp.os.unix.linux.misc

1 participants
0 comments

bbdb cvs archive 25 years, 5 months

Didier Verna

The latest bbdb archive from cvs seem to use the function extent-data. I vaguely remember having fixed this problem (or someone else, maybe) a while ago. Is the cvs version outdated ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Out of toppic: The Halloween Documents 25 years, 5 months

Heiko Münkel

I think everyone, who writes free software should read the so called Halloween Documents on http://www.opensource.org/halloween.html and should be aware, that he is a major enemie of `Billie Boy' and therefore must be bought or destroyed ... Regards, Heiko

1 participants
0 comments

Re: XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux) 25 years, 5 months

William M. Perry

Martin Buchholz <martin(a)xemacs.org> writes: > >>>>> "Bill" == William M Perry <wmperry(a)aventail.com> writes: > > Bill> This brings up a question I have always had about the XEmacs autoconf > Bill> support. Why is it that you cannot simply do `autoreconf'. Touching > Bill> config.h.in by hand is gross. I completely thrashed a XEmacs source tree > Bill> once when I did an autoreconf - the config.h.in it produced was unusable. > > I've never used autoreconf. It's supposed to be a front-end to autoconf > + autoheader - but we don't use autoheader. We hand-maintain our own > config.h.in. > > Bill> Also, if you do it in the current tree I get the oh-so-helpful error from > Bill> autoreconf. :) > > Bill> /usr/bin/autoreconf: test: src/config.h: binary operator expected > > Bill> How close are we to being able to lose Makefile.in.in completely? > > Only a few light years. > > A project worth investigating is trying to migrate to automake > directly. But I'm not sure offhand what it would buy us. Maybe we > would get libtool shared lib support for free? Now that would be > worth something. Adding libtool support to something already using autoconf is pretty trivial - I did it to our entire source tree here at aventail in about 3 hours. Now 7 of our libraries build shared on all the platforms we support... fun fun. -Bill P.

1 participants
0 comments

Re: XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux) 25 years, 5 months

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > A project worth investigating is trying to migrate to automake > directly. But I'm not sure offhand what it would buy us. Maybe we > would get libtool shared lib support for free? What would that buy? I thought libtool was for building shared libraries. The only thing close in the XEmacs tree is building as an external widget. Have more than a dozen people ever even tried it?

1 participants
0 comments

XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux) 25 years, 5 months

William M. Perry

Martin Buchholz <martin(a)xemacs.org> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> Charles G Waldman <cgw(a)pgt.com> writes: > >> On a more general note, why is HAVE_FSYNC being handled the way it > >> is (in src/sysfile.h) instead of by the configure script? The > >> existing logic seems convoluted - since Linux #defines USG, sysfile > >> decides not to #define HAVE_FSYNC, even though Linux has fsync. Am > >> I misunderstanding the purpose/meaning of the HAVE_FSYNC symbol? > >> What does USG have to do with it? > > Hrvoje> Only Martin is truly competent to answer this, but if I had to guess, > Hrvoje> I'd say it's a remnant of the pre-configure period, when all the > Hrvoje> HAVE_* symbols were handles by s/m files. If we want to use > Hrvoje> HAVE_FSYNC, we should simply check it via Autoconf. > > Martin here. > > There are still s&m files that include usg-*.h. I'd like to nuke > them, but am afraid. > > HAVE_FSYNC looks like something that ought to be autoconfiscated, but > I don't know enough about fsync(). > > In the dark ages before autoconf, everything was hard-coded into the > s&m files. At that time, it looked pretty clever to have a usg5-4.h > `subroutine'. > > One could just add fsync to the list of functions on that long > AC_CHECK_FUNCS line in configure.in, and add > > #undef HAVE_FSYNC > > to src/config.h. This brings up a question I have always had about the XEmacs autoconf support. Why is it that you cannot simply do `autoreconf'. Touching config.h.in by hand is gross. I completely thrashed a XEmacs source tree once when I did an autoreconf - the config.h.in it produced was unusable. Also, if you do it in the current tree I get the oh-so-helpful error from autoreconf. :) /usr/bin/autoreconf: test: src/config.h: binary operator expected How close are we to being able to lose Makefile.in.in completely? -Bill P.

2 participants
1 comments

[Failure] 21.0 "Poitou" XEmacs Lucid on mips-unknown-linux 25 years, 5 months

Michael Hill

I just got SGI/Linux installed on my Indy (there's no X server yet). The changes below were suggested by the FSF Emacs 19.34 patch on the SGI/Linux ftp server; FSF Emacs runs in console mode. Compiler and libs are Red Hat 5.1 vintage. uname -a: Linux mdhill 2.1.100 #7 Wed Nov 4 00:01:10 EST 1998 mips unknown ./configure '--without-x' '--gung-ho' '--use-union-type' '--package-path=/mnt/debian/xemacs' XEmacs 21.0 "Poitou" configured for `mips-unknown-linux'. Where should the build process find the source code? /mnt/debian/xemacs-21.0-b57 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/mips.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? none Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. 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. Using indexed lrecord implementation. [Build fails at this point:] Dumping under the name xemacs Purespace usage: 631320 of 631320 (100%). XEmacs: Couldn't find segment next to .bss in /usr/src/xemacs-21.0-b57/src/temacs make[2]: [xemacs] Error 1 (ignored) Testing for Lisp shadows ... /bin/sh: ./xemacs: Permission denied make[2]: Leaving directory `/usr/src/xemacs-21.0-b57/src' make[1]: Leaving directory `/usr/src/xemacs-21.0-b57/src' Building finder database ... /bin/sh: /usr/src/xemacs-21.0-b57/src/xemacs: Permission denied make: *** [lisp/finder-inf.el] Error 126 Thanks, Mike -- Michael Hill Tottenham, Canada mdhill(a)interlog.com --- configure.in~ Tue Sep 29 17:19:26 1998 +++ configure.in Fri Nov 6 22:58:17 1998 ＠＠ -1482,6 +1482,9 ＠＠ dnl Linux/68k m68k-*-linux* ) machine=m68k opsys=linux ;; + dnl Mips Linux-based GNU system + mips*-*-linux* ) machine=mips opsys=linux ;; + esac if test -z "$machine" -o -z "$opsys"; then --- src/m/mips.h~ Tue Mar 31 15:12:25 1998 +++ src/m/mips.h Fri Nov 6 23:07:13 1998 ＠＠ -106,16 +106,25 ＠＠ /* This machine requires completely different unexec code which lives in a separate file. Specify the file name. */ +#ifndef __linux__ +#undef UNEXEC #define UNEXEC "unexmips.o" +#endif /* not __linux__ */ /* Describe layout of the address space in an executing process. */ +#ifdef __linux__ +#define TEXT_START 0x00400000 +#define DATA_START 0x10000000 +#define DATA_SEG_BITS 0x10000000 +#else /* not __linux__ */ #define TEXT_START 0x400000 #define DATA_START 0x800000 +#endif /* __linux__ */ /* Alter some of the options used when linking. */ -#ifndef NEWSOS5 +#if !defined(NEWSOS5) && !defined(__linux__) #ifdef BSD /* DECstations don't have this library. */ ＠＠ -138,9 +147,9 ＠＠ #define C_DEBUG_SWITCH "-O -g3" #endif /* not BSD */ -#endif /* not NEWSOS5 */ +#endif /* not NEWSOS5 && not __linux__ */ -#ifndef NEWSOS5 +#if !defined (NEWSOS5) && !defined (__linux__) #ifdef USG /* Don't try to use SIGIO even though it is defined. */ ＠＠ -167,4 +176,4 ＠＠ #define TERMINFO #undef MAIL_USE_FLOCK /* Someone should check this. */ #endif /* BSD */ -#endif /* not NEWSOS5 */ +#endif /* not NEWSOS5 && not __linux__ */

1 participants
0 comments

laser printer toner advertisement 25 years, 5 months

art1234＠pacsun.com

BENCHMARK SUPPLY 7540 BRIDGEGATE COURT ATLANTA GA 30350 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-532-7170**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. NOTE NUMBER (3): OWNERS OF ANY OF THE DOMAINS THAT APPEAR IN THE HEADER OF THIS MESSAGE,ARE IN NO WAY ASSOCIATED WITH, PROMOTING, DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS ADVERTISED HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE THEREOF.

1 participants
0 comments

ftp://ftp.xemacs.org/pub/sites/ftp.gnome.org/imlib/TAR/ 25 years, 5 months

SL Baur

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