October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Nils Bokermann

Hi! The next problem ;) [Should I better build my own xemacs and not get the one from debian ;] When calling virtual-folder-member in: (setq vm-virtual-folder-alist ;; note the magic of creating the first element of the alist with ;; a symbol that needs to be eval'ed at assignment time (append (list (list (symbol-value 'my-vm-virtual-leftovers-folder) (list (list "INBOX") '(not (virtual-folder-member))))) '(("automake" (("INBOX") (sender-or-recipient "automake＠"))) ... The following error occurs: Signaling: (void-function nil) nil([[#<marker at 1 in INBOX 0x82f56dc> #<marker at 70 in INBOX 0x82f56c4> nil #<marker at 1920 in INBOX 0x85d1314> #<marker at 2967 in INBOX 0x82f56ac> #<marker at 2968 in INBOX 0x82f5694>] ["1" " 1" nil #<marker at 1 in INBOX Summary 0x864548c> #<marker at 64 in INBOX Summary 0x86454a4> <<>> <-- From_ "0" #<buffer "INBOX"> nil nil nil nil nil nil nil nil #<extent (1, 64) H 0x83598bc in buffer INBOX Summary>] [nil nil nil nil nil nil nil nil nil] ["1047" "Thu" "29" "January" "1998" "13:57:51" "+0100" "Nils Bokermann" "bokerman(a)post.uni-bielefeld.de" nil "30" "Back in Town" "^From:" nil nil "1" nil nil (number " " mark " Nils Bokermann Jan 29 30/1047 " thread-indent "\"Back in Town\"\n") nil nil] [nil <v> nil nil nil]] "automake＠") apply(nil [[#<marker at 1 in INBOX 0x82f56dc> #<marker at 70 in INBOX 0x82f56c4> nil #<marker at 1920 in INBOX 0x85d1314> #<marker at 2967 in INBOX 0x82f56ac> #<marker at 2968 in INBOX 0x82f5694>] ["1" " 1" nil #<marker at 1 in INBOX Summary 0x864548c> #<marker at 64 in INBOX Summary 0x86454a4> <<>> <-- From_ "0" #<buffer "INBOX"> nil nil nil nil nil nil nil nil #<extent (1, 64) H 0x83598bc in buffer INBOX Summary>] [nil nil nil nil nil nil nil nil nil] ["1047" "Thu" "29" "January" "1998" "13:57:51" "+0100" "Nils Bokermann" "bokerman(a)post.uni-bielefeld.de" nil "30" "Back in Town" "^From:" nil nil "1" nil nil (number " " mark " Nils Bokermann Jan 29 30/1047 " thread-indent "\"Back in Town\"\n") nil nil] [nil <v> nil nil nil]] "automake＠") vm-vs-or([[#<marker at 1 in INBOX 0x82f56dc> #<marker at 70 in INBOX 0x82f56c4> nil #<marker at 1920 in INBOX 0x85d1314> #<marker at 2967 in INBOX 0x82f56ac> #<marker at 2968 in INBOX 0x82f5694>] ["1" " 1" nil #<marker at 1 in INBOX Summary 0x864548c> #<marker at 64 in INBOX Summary 0x86454a4> <<>> <-- From_ "0" #<buffer "INBOX"> nil nil nil nil nil nil nil nil #<extent (1, 64) H 0x83598bc in buffer INBOX Summary>] [nil nil nil nil nil nil nil nil nil] ["1047" "Thu" "29" "January" "1998" "13:57:51" "+0100" "Nils Bokermann" "bokerman(a)post.uni-bielefeld.de" nil "30" "Back in Town" "^From:" nil nil "1" nil nil (number " " mark " Nils Bokermann Jan 29 30/1047 " thread-indent "\"Back in Town\"\n") nil nil] [nil <v> nil nil nil]] (sender-or-recipient "automake＠")) apply(vm-vs-or [[#<marker at 1 in INBOX 0x82f56dc> #<marker at 70 in INBOX 0x82f56c4> nil #<marker at 1920 in INBOX 0x85d1314> #<marker at 2967 in INBOX 0x82f56ac> #<marker at 2968 in INBOX 0x82f5694>] ["1" " 1" nil #<marker at 1 in INBOX Summary 0x864548c> #<marker at 64 in INBOX Summary 0x86454a4> <<>> <-- From_ "0" #<buffer "INBOX"> nil nil nil nil nil nil nil nil #<extent (1, 64) H 0x83598bc in buffer INBOX Summary>] [nil nil nil nil nil nil nil nil nil] ["1047" "Thu" "29" "January" "1998" "13:57:51" "+0100" "Nils Bokermann" "bokerman(a)post.uni-bielefeld.de" nil "30" "Back in Town" "^From:" nil nil "1" nil nil (number " " mark " Nils Bokermann Jan 29 30/1047 " thread-indent "\"Back in Town\"\n") nil nil] [nil <v> nil nil nil]] (sender-or-recipient "automake＠")) vm-build-virtual-message-list(nil) vm-visit-virtual-folder("automake") apply(vm-visit-virtual-folder "automake") vm-menu-run-command(vm-visit-virtual-folder "automake") eval((vm-menu-run-command (quote vm-visit-virtual-folder) "automake")) Yes, it's the sample config from the VM-FAQ. Bye, Nils P.S.: I think it's just one key -- just as last time, but I looked for it the whole evening and I don't know how to do. Bye, Nils -- Nils Bokermann Phone: +49 521 88074398

1 participants
0 comments

RE: Startup Warning with 21.1.7 24 years, 6 months

Jeff Paulsen

>When I now start xemacs, I get the following > >(1) (warning/warning) Autoload error in: >/homes/washington/colman/lib/xemacs/xemacs-packages/lisp/lookup >/auto-autoloads: > Cannot open load file: mule I get a whole bunch of these. I used to just get a few, then I installed some more packages - now I get maybe a dozen. it doesn't seem to hurt anything, but it is annoying. jeff paulsen

1 participants
0 comments

mailcrypt/vm problem 24 years, 6 months

Nils Bokermann

Hi! It might be my problem (Yes, I too mad ;), but I hope, someone can help: calling mailcrypt-verify from vm causes the following error: Signaling: (invalid-function (macro . #<compiled-function nil "...(4)" [(and vm-mail-buffer (or (buffer-name vm-mail-buffer) (error "Folder buffer has been killed.")) (set-buffer vm-mail-buffer))] 1>)) vm-select-folder-buffer() mc-vm-verify-signature() #<compiled-function nil "...(27)" [major-mode mc-modes-alist mode-alist verify mc-verify-signature func] 3 ("/usr/share/xemacs21/packages/lisp/mailcrypt/mc-toplev.elc" . -5554) nil>() call-interactively(mailcrypt-verify) command-execute(mailcrypt-verify t) execute-extended-command(nil) call-interactively(execute-extended-command) So. I'm using XEmacs 21.1 (patch 7) "Biscayne" [Lucid] (i386-debian-linux, Mule) of Wed Oct 27 1999 on hercules, and mailcrypt 2.02, vm 1.21. Thanks for help :) Bye, nils -- Nils Bokermann Phone: +49 521 88074398

2 participants
1 comments

latest cvs temacs segfaults 24 years, 6 months

Michael Harnois

Starting program: /usr/src/xemacs/src/temacs Program received signal SIGSEGV, Segmentation fault. 0x8131132 in Fboundp (symbol=0) at /usr/src/xemacs-21.2/src/symbols.c:492 492 CHECK_SYMBOL (symbol); (gdb) where #0 0x8131132 in Fboundp (symbol=0) at /usr/src/xemacs-21.2/src/symbols.c:492 #1 0x80517bc in memory_full () at /usr/src/xemacs-21.2/src/alloc.c:264 #2 0x8051817 in xmalloc (size=4) at /usr/src/xemacs-21.2/src/alloc.c:282 #3 0x807a024 in sort_args (argc=1, argv=0xbffffb64) at /usr/src/xemacs-21.2/src/emacs.c:1965 #4 0x80794b0 in xemacs_21_2_b19_i686_pc_linux (argc=1, argv=0xbffffb64, envp=0xbffffb6c, restart=0) at /usr/src/xemacs-21.2/src/emacs.c:588 #5 0x807a6e3 in main (argc=1, argv=0xbffffb64, envp=0xbffffb6c) at /usr/src/xemacs-21.2/src/emacs.c:2232 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org The first thing you should do when you get up is read the obituaries. You never know when you'll see a name that will just make your day. --Ed Salisbury

1 participants
0 comments

Patch cue for 21.2 core flushed 24 years, 6 months

Jan Vroonhof

I have applied all patches submitted after 19990720 that didn't make it into 21.2 yet. Please yell if I missed something. Jan

3 participants
2 comments

Re: Unmark pdumped objects 24 years, 6 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > My feeling is that o-c-f should be called on *all* compiled-function > objects at dump time. Then it's OK with me.

1 participants
0 comments

Re: Patches Applied for 21.1.8 24 years, 6 months

Vin Shelton

2 participants
1 comments

Re: Announcements 24 years, 6 months

Jason R Mastaler

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > One thing we could do is have all xemacs-announce messages > > automatically go to comp.emacs.xemacs like they go to xemacs-beta. > > What do people think about this idea? > > I think we should NOT annouce beta versions (i.e. 21.2.x) on c.e.x > > All the other announcements (i.e. 21.1.x, sumos, etc.) are OK for > Usenet, in my opinion. Well, the idea is to make this automated so that the process is easy and nothing slips through the cracks. I'd like to have xemacs-announce messages go to comp.emacs.xemacs, but you have a good point about the beta announcements. Perhaps beta announcements should not go to xemacs-announce but to xemacs-beta only. This information is only useful for those reading xemacs-beta anyway, right?

3 participants
2 comments

"Unknown Host" Update, more evidence 24 years, 6 months

Gerald Gutierrez

Okay it happened again. Attempting to reply to an email through VM & got the unknown host error. This time I had some things ready. First I know I can ping it: -------------------------------------------------------------- ** Ping ** ping ** smtp.intergate.bc.ca PING smtp.intergate.ca (207.34.179.20): 56 data bytes 64 bytes from 207.34.179.20: icmp_seq=0 ttl=253 time=179.1 ms 64 bytes from 207.34.179.20: icmp_seq=1 ttl=253 time=160.0 ms 64 bytes from 207.34.179.20: icmp_seq=2 ttl=253 time=150.7 ms 64 bytes from 207.34.179.20: icmp_seq=3 ttl=253 time=150.2 ms --- smtp.intergate.ca ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 150.2/160.0/179.1 ms Process Ping smtp.intergate.bc.ca finished -------------------------------------------------------------- and I know I can contact the server via telnet. I found that VM uses open-network-stream to make a network connection, so I learned a little elisp and executed the following: -------------------------------------------------------------- (setq process (open-network-stream "my-test-stream" "*scratch*" "smtp.intergate.bc.ca" "smtp")) -------------------------------------------------------------- and sure enough this paused Emacs for a while and then spit out the "unknown host" message in the minibuffer. On restarting Emacs and running this again, it made the connection just fine and the SMTP greetings line showed up in my scratch buffer. I've looked at the .el files and know that open-network-stream uses open-network-stream-internal, which Emacs says is a "built-in function". I gather that means it's not written in Lisp but is a part of Emacs itself. It seems more evident than ever that this is a Emacs problem (bug even!). I'd look further, but school is like a gas; it expands to consume all free time. I guess what I'm looking for is someone to concur that based on these observations it's a problem somewhere inside Emacs and not something I'm just doing wrong. Solution follows from there ...

4 participants
3 comments

Re: Unmark pdumped objects 24 years, 6 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > Hence it has gone with my killer blow on the purespace code. Well, > I don't think I have a "in the dumping" flag handy enymore, but it > is easy enough to add. Hvroje seems to think that the space > expansion due to the systematic use of o-c-f may be a problem, > though. Comments? Only "may". If you can find the size of the dumped code with and without o-c-f dumping and present us the two numbers, it might very well prove that the size increase is irrelevant.

3 participants
3 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 October 1999