May 1999 - XEmacs-Beta - XEmacs Mailing List Archives

digital signature test, xemacs-dist@xemacs.org public key 26 years, 1 month

SL Baur

Please test this if you can. If it works, I will resume signing files on the XEmacs ftp site. gpg (GnuPG) 0.9.7; Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v0.9.7 (OSF1) Comment: For info see http://www.gnupg.org mQGiBDZnjv0RBACWfrIjrM0NVl9mw7uDEp2506m8jlO9w/kODRI0ZL72Zaesfj1x /lmXm/ZDUms8YCMnHoipZF1F1ygqLz8MLcmu4p5t1Vne8fEOrG00r+DbvZDefcgt FgvIymeI6SaRBhX0bu/wgh2zzEH7/tdJyLttNIJxOUWVBBn6WYfAeJcF5wCgngEk m+G0JHSg1EcfUneW+uU1ryMD/3DzmD8olJAdLKCG4ThOXw7hxVL9TqlVCkpz+FbY GzJG9P62xBa7nT6JzXmoMH7IzXKydPYBW86vpY63mcjfAD+k9MnX8oXm5bjnD7IR AvaefbKoAYXxyJKiQIJr6UjXlUu5l1ZUs1PTG+Zo7ezl2mfihqiSKa9GToP6Xi0C Da5RA/93c59eO0OtvdJKrJQbnWE6jBFCp9t+Ma3jbJRnNZBg7U/Peqskv+pItCyC dXD1hufWFVJuv7ZTpXrtIcAjB2KG7P7ZNLJUiSA4UIOi03EvqXXWw3WW340mrRG/ jPnWHl9+AmLNN4qfdV7QMwhvFr3/n5nvka29LrbA7XlOIDJ+PrRgWEVtYWNzIERp c3RyaWJ1dGlvbiBCdWlsZGVyIChLZXkgdXNlZCBmb3Igc2lnbmluZyBYRW1hY3Mg ZGlzdHJpYnV0aW9ucykgPHhlbWFjcy1kaXN0QHhlbWFjcy5vcmc+iF0EExECAB0F AjZnjv0FCQlmAYADCwQDBRUDAgYBAxYCAQIXgAAKCRASeDZN3PgLawalAJ4hbgZv RU/IB5eDGN/y6cb0wnnOhACgmtu4P3nzaeO/hJogx6y/3QT6bVk= =IzNk -----END PGP PUBLIC KEY BLOCK----- -- I protest the NATO war in Yugoslavia.

2 participants
1 comments

Re: gnupg for Digital UNIX 26 years, 1 month

SL Baur

Kevin Oberman <oberman(a)es.net> writes in xemacs-beta(a)xemacs.org: ... >> How do you eliminate the myriad of broken preprocessor lines? The >> gnupg maintainer, evidently, is unwilling to convert them to standard >> C. > On DU the -std1 flag enforces ANSI compliance. -std is ANSI "with > some relaxations" and it seems to be happy with the pre-processor lines. Whee. That does the trick. ... > In any case, gnupg-0.9.6 now passes all 23 tests: Very good. ... > I will attach the diffs for the two files I edited. The edit to secmem > is clearly a kludge and I need to find the real problem, so I should > have an additional patch before too much longer. O.K. > I consider the patch to configure to be a fix and don't have any > plan to do anything else to it. What flavor of ptys are you using? The `expect' binary someone built here is broken because it assumes the wrong kind, I believe. Perhaps this is an aspect of the same problem? The system has no more ptys. Ask your system administrator to create more. while executing "spawn ../g10/gpg --no-batch --quick-random --homedir . --gen-key" FAIL: genkey1024.test I have `pseudo-device pty 255' in my kernel config file and there are only a handful of ptys currently in use. The -lc problem was fixed another way in 0.9.7.

1 participants
0 comments

open parts 26 years, 1 month

Neal D. Becker

There is a very interesting story on KDE 2.0 at: http://linuxtoday.com/stories/6262.html I wonder whether an embedded xemacs could be useful?

1 participants
0 comments

Re: gnupg for Digital UNIX 26 years, 1 month

SL Baur

Kevin Oberman <oberman(a)es.net> writes in xemacs-beta(a)xemacs.org: > I have almost successfully built gnupg-0.9.6 on DU 4.0d. Cool. > The main requirement is to edit all occurrences of '-lc' out of > configure except for the two in comment lines for checking for dlopen > in libc. > Once that was done, it compiled fine with: > "setenv CC cc;setenv CFLAGS -std;configure;gmake; > (gmake is gnu make. The default make dumps core in 'make doc'.) > It builds cleanly, but it fails three rather critical checks, How do you eliminate the myriad of broken preprocessor lines? The gnupg maintainer, evidently, is unwilling to convert them to standard C. > encrypt.test, encryptp.test and armencryptp.test. It's my guess that > it is a 32 bit dependency in one of the encryption routines. I will > continue to beat on it as time permits. These things can be painful to > track down, but I believe I'll get there eventually. Try eliminating the `informational' comment `Warning using insecure memory' and see if the tests pass. With 0.9.6 and egcs I got everything but the genkey1024 test to pass and that failure was likely due to a broken installation of expect. I haven't tried compiling 0.9.7 with egcs yet and I haven't come close to getting a working version with the DEC C compiler. > If someone else gets it working, please let me know. I hate to waste > time re-inventing wheels. Me too. I need it working on either Solaris 2.6 or DU 4.0 in order to start signing tarballs again. Sigh. -- I protest the NATO war in Yugoslavia.

2 participants
1 comments

Re: Lisp, Siod and LyX, Guile and ANSI Lisp 26 years, 1 month

John Jones

>>>>> Uwe Brauer writes: > Thanks for the link. This I was looking for. As I understood it > Guile is not considered seriously, why? You may be aware of this example already, but the spreadsheet siag can use either guile or siod as an extension language. It runs considerably slower when using guile. I know that several people have written against using siod in such a way that you would think that it is unsuitable for anything. Yet, somehow it works well for siag. The answer for LyX may have more to do with how much you expect to implement in the extension language. John Jones jj(a)asu.edu

1 participants
0 comments

Re: XEmacs 21.1.2 lib-src/Makefile "utilities run internally by XEmacs" not being installed 26 years, 1 month

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Which utilities are not being installed for you? > > $ ls /usr/local/lib/xemacs-21.1-p2/alphaev56-dec-osf4.0e > DOC fakemail make-path sorted-doc > add-big-package.sh gnuserv mmencode vcdiff > config.values gzip-el.sh movemail wakeup > cvtmail hexl profile yow > digest-doc make-docfile rcs2log Are you using GNU make? Maybe he isn't. I seem to remember this being fixed when GNU make is used. It's probably a subtle bug in a Makefile. > -- > I protest the NATO war in Yugoslavia. Booo!

1 participants
0 comments

Re: Lisp, Siod and LyX, Guile and ANSI Lisp 26 years, 1 month

Hrvoje Niksic

"Uwe Brauer" <oub(a)eucmos.sim.ucm.es> writes: > Thanks for the link. This I was looking for. As I understood it > Guile is not considered seriously, why? Because Michael doesn't like it. (I'm not being insulting here; I'm serious. Other people on the list don't appear to know much about Scheme, and Michael has expressed his dislike for guile on many occasions.)

1 participants
0 comments

Re: Lisp, Siod and LyX, Guile and ANSI Lisp 26 years, 1 month

Jan Vroonhof

"Uwe Brauer" <oub(a)eucmos.sim.ucm.es> writes: > Thanks for the link. This I was looking for. As I understood it Guile > is not considered seriously, why? You probably mean the fact that it is not prominently listed as a scheme candidate on Michaels web page. If you read the archives of the discussion you'll see that Michael is not a fan of conservative garbage collection for long running programs like XEmacs and Guile uses a conservative garbage collector. Read his original arguments so see why, that is better than me paraphrasing them. Jan

1 participants
0 comments

Re: Lisp, Siod and LyX, Guile and ANSI Lisp 26 years, 1 month

Michael Sperber

>>>>> "Uwe" == Uwe Brauer <oub(a)eucmos.sim.ucm.es> writes: Uwe> Since Guile was also recommended by for example Karl M. Hegbloom, Uwe> I would like to add the following questions: Uwe> 1. Is it likely that Gnuemacs and/or Xemacs will substitute emacs lisp Uwe> by guile? Given the fact that RMS is involved in the Guile rpoject Uwe> I think it is not improbable for gnuemacs, what then about Xemacs? Uwe> 2. What is about standard ANSI Lisp? Eric Naggum I think was Uwe> proposing this for a while. There has been very extensive discussion about this on the list. A (subjective) synopsis is at http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-gener... -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: old dates invalid? 26 years, 1 month

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> I don't know. The representation of times in XEmacs needs to be >> revisited now that we have larger integers and the fact that we have >> to deal with the y2038 problem eventually. > I checked encode-time yesterday evening. It just calls the system > library functions. Maybe the FSF uses their own routines now? I just checked a recent set of FSF sources and they use an imported copy of mktime.c from the GNU C library. -- I protest the NATO war in Yugoslavia.

1 participants
0 comments

2025

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