July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Patch to package-get.el 27 years, 2 months

Adrian Aichner

>>>>> "BAW" == Barry A Warsaw <bwarsaw(a)CNRI.Reston.Va.US> writes: Hello Barry, the ph package was swallowed by the eudc package, I believe. This comes straight out of package-get-base.el of 21.0-b50: (eudc (standards-version 1.0 version "1.10" author-version "1.10" date "1998-07-12" build-date "1998-07-19" maintainer "Oscar Figueiredo <Oscar.Figueiredo(a)epfl.ch>" distribution stable priority low category "comm" dump nil description "Emacs Unified Directory Client (LDAP, PH)." filename "eudc-1.10-pkg.tar.gz" md5sum "90e03dbd32651e4b24f973c29665a709" size 41343 provides (eudc eudc-ldap eudc-ph) requires (fsf-compat xemacs-base) type regular)) Regards, Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

2 participants
1 comments

Patch to package-get.el 27 years, 2 months

Barry A. Warsaw

If package-get-all is called for a package that doesn't exist, you get an error. This happened to me in b50 when I ran package-get-update-all with Steve's updated package-get-base.el because the 'ph package wasn't in the list (I presume). Here's a patch that at least avoids the error, although I'm not sure it's the right fix. -Barry *** package-get.el 1998/07/24 20:19:18 1.1 --- package-get.el 1998/07/24 20:19:57 *************** *** 185,215 **** the-package version)) (this-requires (package-get-info-prop this-package 'requires)) ) ! (setq version (package-get-info-prop this-package 'version)) ! (unless (package-get-installedp package version) ! (package-get package version)) ! (setq fetched-packages ! (append (list package) ! (package-get-info-prop this-package 'provides) ! fetched-packages)) ! ;; grab everything that this package requires plus recursively ! ;; grab everything that the requires require. Keep track ! ;; in `fetched-packages' the list of things provided -- this ! ;; keeps us from going into a loop ! (while this-requires ! (if (not (member (car this-requires) fetched-packages)) ! (let* ((reqd-package (package-get-package-provider ! (car this-requires))) ! (reqd-version (cadr reqd-package)) ! (reqd-name (car reqd-package))) ! (if (null reqd-name) ! (error "Unable to find a provider for %s" (car this-requires))) ! (setq fetched-packages ! (package-get-all reqd-name reqd-version fetched-packages))) ! ) ! (setq this-requires (cdr this-requires))) ! fetched-packages ! )) ;;;###autoload (defun package-get (package &optional version conflict) --- 185,217 ---- the-package version)) (this-requires (package-get-info-prop this-package 'requires)) ) ! (when this-package ! (setq version (package-get-info-prop this-package 'version)) ! (unless (package-get-installedp package version) ! (package-get package version)) ! (setq fetched-packages ! (append (list package) ! (package-get-info-prop this-package 'provides) ! fetched-packages)) ! ;; grab everything that this package requires plus recursively ! ;; grab everything that the requires require. Keep track ! ;; in `fetched-packages' the list of things provided -- this ! ;; keeps us from going into a loop ! (while this-requires ! (if (not (member (car this-requires) fetched-packages)) ! (let* ((reqd-package (package-get-package-provider ! (car this-requires))) ! (reqd-version (cadr reqd-package)) ! (reqd-name (car reqd-package))) ! (if (null reqd-name) ! (error "Unable to find a provider for %s" ! (car this-requires))) ! (setq fetched-packages ! (package-get-all reqd-name reqd-version fetched-packages))) ! ) ! (setq this-requires (cdr this-requires))) ! fetched-packages ! ))) ;;;###autoload (defun package-get (package &optional version conflict)

1 participants
0 comments

Re: [crash] on Solaris 2.5.1 27 years, 2 months

Gunnar Evermann

Robert_Pluim(a)BayNetworks.COM (Robert Pluim) writes: > At 16:40 23/07/98 +0200, Gunnar Evermann wrote: > >Robert_Pluim(a)BayNetworks.COM (Robert Pluim) writes: > >% xemacs -q > > > >C-x C-f ~/test.c RET (open new file in cc-mode) > > > >M-; M-; (press indent-for-comment twice) > >---------------------------------------------------------------------- > > > >Does this work (i.e. crash) for you? The proposed solution was: > > Yep, that does it for me. It's definitely a bug in gcc (and apparently egcs). I played around a bit more and found that the minimal optimization options that produce the crash are: -O1 -fcse-skip-blocks -fschedule-insns A good set of options to avoid the crash seems to be: -O3 -fno-schedule-insns I started looking at the assembler and the RTL stuff generated by the different compiler-passes but got lost real quick. Maybe somebody who is a lot smarter than I am can make some sense of this. FWIW the crash occurs at the (inlined) call to SYNTAX_CODE in the macro-expanded SYNTAX() at search.c:845 Steve, how shall we proceed now? I guess quite a few people will get hit by this if we don't find a way to fix the problem... How about an entry in PROBLEMS? Has anybody any experience filing bug reports with the gcc/egcs-folks? I guess they won't be thrilled if I mail them xemacs-21.0-b50.tar.gz, right? -- Gunnar Evermann Natural Language Systems Group, University of Hamburg EMail: Gunnar.Evermann(a)nats.informatik.uni-hamburg.de

1 participants
0 comments

[PATCH] vc-cc: minor "feature" fixes 27 years, 2 months

Peter Windle

Applied against vc-cc :version 1.05, ChangeLog enclosed. Actually use the vc-checkout-switches variable as intended. Clean up comment at check out, to avoid spurious newlines when checking in outside vc-cc. -- pete "..." --- lisp/vc-cc/ChangeLog~ Sun Jul 19 00:03:08 1998 +++ lisp/vc-cc/ChangeLog Fri Jul 24 15:56:15 1998 ＠＠ -1,3 +1,9 ＠＠ +1998-07-24 Peter Windle <peterw(a)ugsolutions.com> + + * vc.el (vc-backend-checkout): Use vc-checkout-switches when + checking out. Clean up comment with vc-cleanup-comment; this was + previously done on checkin only. + 1998-07-18 SL Baur <steve(a)altair.xemacs.org> * dumped-lisp.el: Removed. --- lisp/vc-cc/vc.el~ Fri Jul 10 00:57:09 1998 +++ lisp/vc-cc/vc.el Fri Jul 24 16:00:59 1998 ＠＠ -2518,7 +2518,9 ＠＠ (let ((filename (or workfile file))) (message "Checking out %s..." filename) (save-excursion - ;; Change buffers to get local value of vc-checkin-switches. + ;; Clean up comment prior to checkout (in case user ci's outside vc-cc) + (setq comment (vc-cleanup-comment comment nil)) + ;; Change buffers to get local value of vc-checkout-switches. (set-buffer (or (get-file-buffer file) (current-buffer))) (vc-backend-dispatch file ＠＠ -2611,7 +2613,8 ＠＠ (vc-do-cleartool-command "co" file comment (and rev "-branch") - rev)) + rev + vc-checkout-switches)) )) (or workfile (vc-file-setprop file

1 participants
0 comments

Re: gnus signals error 27 years, 2 months

Lars Magne Ingebrigtsen

SL Baur <steve(a)xemacs.org> writes: > That's not how it got built, I remove all .elcs before building a Gnus > for distribution. Why shouldn't nnmail.el have a > > (eval-when-compile (require 'gnus-util)) > > in it? It should have. Fix in 5.6.25. -- (domestic pets only, the antidote for overdose, milk.) larsi(a)ifi.uio.no * Lars Magne Ingebrigtsen

1 participants
0 comments

Re: no inline mime images :-( 27 years, 2 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > > The gif one fails only. > > So what's the problem again? No problem. Everything's normal. I just forgot that the last time an image didn't get inlined, it was probably a gif, so I thought there was a problem. But there aren't any problem. Everything's normal. I've started degifizing my life.

1 participants
0 comments

Re: no inline mime images :-( 27 years, 2 months

Adrian Aichner

Steven, XEmacs crashes on this E-mail when I hit SPACE to get beyond the begining of the mail. I can see part of the lastphoto.png image displayed at the beginning of the Article buffer. Here is what I get in the invoking shell, where ec is the following alias: aichner＠tomorrow(32) alias ec ~/sh/editclient.sh !* aichner＠tomorrow(33) aichner＠tomorrow(31) ld.so.1: xemacs: fatal: relocation error: symbol not found: TIFFClientOpen: referenced in xemacs aichner＠tomorrow(31) Sorry for the mildly useless stack traceback: -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

Re: no inline mime images :-( 27 years, 2 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> O.K. So we're playing 20 questions. Which (if any) of the following >> fail? Note that failure on GIF will be standard come the next release. > The gif one fails only. So what's the problem again? GIF isn't supposed to work. GIF is evil. Using GIF endangers your immortal soul. Just Say No to GIF. If you wish to pay a license to Unisys for LZW compression in order to use GIF, be our guest, but we the XEmacs developers are not going to support it.

1 participants
0 comments

Re: [21.0-b50] Bug in Quail/latin-postfix? 27 years, 2 months

Didier Verna

Marcus Thiessel <thiessel(a)hpbbse.bbn.hp.com> writes: > When I use Quail and latin-postfix as input method I sometimes run > into > > Symbol's function definition is void: listify-key-sequence This function has been completely removed. Since quail was using it, I just replaced the call (there was only one I think) with the function's body itself. Maybe you have an old version of quail ? BTW, after grepping listify-key-sequence on all packages that I have, I find that it's still present in eterm/term.el. Moreover, there's a mil-listify-key-sequence in mule-base/isearch-mule. I don't know if it's related. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: no inline mime images :-( 27 years, 2 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > O.K. So we're playing 20 questions. Which (if any) of the following > fail? Note that failure on GIF will be standard come the next release. The gif one fails only.

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