slime-devel July 2005

slime-devel@common-lisp.net

37 participants
54 discussions

[slime-devel] Re: It's not just me!
by Hoehle, Joerg-Cyril 07 Jul '05

07 Jul '05

Hi, >Given some more time, I'll start clisp in a console window, >connect via socket and see if/how ^C gets propagated. I now started clisp in a separate console window on MS-Windows-2k used M-x slime-connect. Slime does not know how to interrupt CLISP. (signal-process (clisp's PID) 'SIGINT) does not work -- as expected. (signa-process (get-buffer-process ...)) does not work either, because although Emacs' socket-connection is mapped to a process object, signaling it does not work -- (process-id) returns nil, not an integer. Then I hit ^C in the console window. To my surprise, I got the REPL in that window. I had expected the slime debug driver to be active, and to send the break interaction to the Emacs slime debugger?!? [8]> (swank:create-server) ;; Swank started at port: 4005. ;; Connection to Emacs lost. ;; [ READ-CHAR: Ctrl-C: User break ] 4005 [9]> OTOH, entering (break) in the slime REPL popped up the SLIME debugger. Obviously, there are real differences in behaviour between Linux and MS-Windows here. Regards, Jorg Hohle.

1 0

[slime-devel] Re: It's not just me!
by Hoehle, Joerg-Cyril 07 Jul '05

07 Jul '05

Helmut Eller wrote: >I guess SIGINT is not the Windows way and something else should be >used instead. Indeed. I now launched clisp via clisp.exe which starts lisp.exe, and the same thing happened as when starting lisp.exe from within a M-x shell: CLISP is not interruptible via signal-process that way. More precisely, (signal-process (pid as reported by CLISP) 'SIGINT) returns -1 and does not stop CLISP. The only thing that works reliably is (signal-process (get-buffer-process ...) 'SIGINT) I'm sure this would also affect other Lisps beside CLISP. So I suggest the following, which maybe could work better: o (at least on MS-Windows) signal the buffer/process that SLIME uses for communication with the Lisp, instead of the Lisp's PID. Obviously, Emacs goes into a lot of effort to make processes receive SIGINT there, even when started from within M-x shell, and there's no need to reproduce this effort in SLIME. I have no idea what to do with a remote Lisp -- can SLIME stop those, in all communication-style configurations? I have no idea how this this affects Lisps with threads and/or :spawn/:io/:fd-handler etc. Given some more time, I'll start clisp in a console window, connect via socket and see if/how ^C gets propagated. Regards, Jorg Hohle.

1 0

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 06 Jul '05

06 Jul '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.721 slime/ChangeLog:1.722 --- slime/ChangeLog:1.721 Tue Jul 5 22:34:31 2005 +++ slime/ChangeLog Wed Jul 6 18:31:56 2005 @@ -1,3 +1,10 @@ +2005-07-06 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-send-sigint): Use the symbol SIGINT stead of the + signal number. Suggested by Joerg Hoehle. + (slime-compile-file): XEmacs needs the buffer as argument to + local-variable-p. Reported by Andy Sloane. + 2005-07-05 Helmut Eller <heller(a)common-lisp.net> The file variable slime-coding can now be used to specify the

1 0

[slime-devel] Re: It's not just me!
by Hoehle, Joerg-Cyril 06 Jul '05

06 Jul '05

Helmut Eller wrote: >The CLISP/Win32 returned -1. clisp-2.33, or 2.33.1, or 2.33.2? clisp from CVS must work. I'll submit a patch to have the older versions work. >I guess SIGINT is not the Windows way and something else should be >used instead. [Aside: I'd be happy if slime.el:slime-send-sigint actually used 'SIGINT. The source code just says '2 -- Emacs-20.7 says: "SIGCODE may be an integer, or a symbol whose name is a signal name." 'SIGINT would be self-documenting.] I did the following experiment, using Emacs-20.7 on MS-Windows-2k M-x shell cd path\to\clisp lisp.exe -M lispinit.mem (ffi:def-call-out getpid (:name "GetCurrentProcessId") (:return-type ffi:uint) (:language :stdc-stdcall) (:library "kernel32.dll")) ;relative path "kernel32.dll" is reported not to work with cygwin -> 1840 M-: (process-id(get-buffer-process(current-buffer))) -> 1812 M-: (signal-process 1840 'SIGINT) ;-> -1 and clisp is not interrupted(!) M-: (signal-process 1812 'SIGINT) ;-> 0 and Emacs titlebar flashes and clisp gets interrupt I.e., in this scenario, the internal pid is useless! Now, using C-u M-x run-lisp, which starts lisp.exe directly instead of going through the cmd.exe proxy, both process ids match, and clisp becomes interruptible by Emacs. SLIME starts clisp the same way (at least in my setup). I have yet to check when clisp is started via clisp.exe which in turn starts lisp.exe. Alas, I know of no other way for signaling an interrupt under Emacs. Regards, Jorg Hohle.

2 1

[slime-devel] today's slime-coding commit & XEmacs
by Andy Sloane 06 Jul '05

06 Jul '05

It seems XEmacs wants two arguments to local-variable-p, so with the latest CVS revision, C-c C-k dies with "Invalid number of arguments to local-variable-p: 1" on line 3778: ,@(if (local-variable-p 'slime-coding) (list (slime-coding-system-cl-name slime-coding)))) The XEmacs docs say the buffer argument is &optional, but it apparently isn't. -Andy

2 1

[slime-devel] July 5th Slime + July 5th OpenMCL
by David Steuber 06 Jul '05

06 Jul '05

I had an odd hiccup here. Starting up slime for the fist time after updating both (and deleting ~/.slime): *inferior-lisp* (load "/Users/david/usr/src/slime/swank-loader.lisp" :verbose t) (swank:start-server "/tmp/slime.11493" :external-format :iso-latin-1-unix) Welcome to OpenMCL Version (Beta: DarwinPPC32) 0.14.3-050705! ? ;Loading #P"/Users/david/usr/src/slime/swank-loader.lisp"... ;Compiling "/Users/david/usr/src/slime/swank-backend.lisp"... ;Loading #P"/Users/david/.slime/fasl/openmcl-0.14-darwin-powerpc/swank- backend.dfsl"... ;Compiling "/Users/david/usr/src/slime/nregex.lisp"... ;Loading #P"/Users/david/.slime/fasl/openmcl-0.14-darwin-powerpc/nregex.dfsl"... ;Compiling "/Users/david/usr/src/slime/metering.lisp"... ;Loading #P"/Users/david/.slime/fasl/openmcl-0.14-darwin-powerpc/ metering.dfsl"... ;Compiling "/Users/david/usr/src/slime/swank-openmcl.lisp"... ;Compiler warnings for "/Users/david/usr/src/slime/swank-openmcl.lisp" : ; Unused lexical variable STREAM, in (MAKE-STREAM-INTERACTIVE (T)). ;Loading #P"/Users/david/.slime/fasl/openmcl-0.14-darwin-powerpc/swank- openmcl.dfsl"... ;Compiling "/Users/david/usr/src/slime/swank-gray.lisp"... ;Loading #P"/Users/david/.slime/fasl/openmcl-0.14-darwin-powerpc/swank- gray.dfsl"... ;Compiling "/Users/david/usr/src/slime/swank.lisp"... ;Loading #P"/Users/david/.slime/fasl/openmcl-0.14-darwin-powerpc/swank.dfsl"... ; Warning: These Swank interfaces are unimplemented: ; (ACTIVATE-STEPPING ADD-FD-HANDLER ADD-SIGIO-HANDLER CALLS-WHO MACROEXPAND-ALL REMOVE-FD-HANDLERS REMOVE-SIGIO-HANDLERS SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN TOGGLE-TRACE) ; While executing: SWANK-BACKEND::WARN-UNIMPLEMENTED-INTERFACES ;Compiler warnings for "/Users/david/usr/src/slime/swank.lisp" : ; Undefined function SWANK-MOP:FINALIZE-INHERITANCE, in (SWANK::EXTRA-KEYWORDS ((EQL 'MAKE-INSTANCE))). ; Undefined function SWANK-MOP:COMPUTE-APPLICABLE-METHODS-USING-CLASSES, in SWANK::APPLICABLE-METHODS-KEYWORDS. ;Compiler warnings for "/Users/david/usr/src/slime/swank-openmcl.lisp" : ; Undefined function #:EQL-SPECIALIZER-OBJECT, in SWANK-BACKEND::SPECIALIZER-NAME. ; Undefined function #:CLASS-NAME, in SWANK-BACKEND::SPECIALIZER-NAME. #P"/Users/david/usr/src/slime/swank-loader.lisp" ? ;; Swank started at port: 61020. 61020 ? What happened was slime did not automatically connect. I was able to connect by doing M-x slime-connect to port 61020. I'm sure it's not a major problem to fix, I just don't have a clue about slime's internals or elisp.

1 1

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 05 Jul '05

05 Jul '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.720 slime/ChangeLog:1.721 --- slime/ChangeLog:1.720 Sun Jul 3 17:55:59 2005 +++ slime/ChangeLog Tue Jul 5 22:34:31 2005 @@ -1,3 +1,22 @@ +2005-07-05 Helmut Eller <heller(a)common-lisp.net> + + The file variable slime-coding can now be used to specify the + coding system to use for C-c C-k. E.g., if the file contains + -*- slime-coding: utf-8-unix -*- Emacs will tell the Lisp side + to call COMPILE-FILE with an external-format argument. + + * slime.el (slime-compile-file): Send the coding system if + the buffer local variable `slime-coding' is bound. + + * swank-backend.lisp, swank-sbcl.lisp, swank-clisp.lisp, + swank-lispworks.lisp, swank-cmucl, swank-allegro.lisp, + swank-abcl.lisp, swank-corman.lisp + (swank-compile-file): New optional argument `external-format'. + + * swank-clisp.lisp (getpid): Undo the last change. + + * swank-corman.lisp (spawn, thread-alive-p): More thread tweaking. + 2005-07-03 Joerg Hoehle <hoehle(a)users.sourceforge.net> * swank-clisp (describe-symbol-for-emacs): Report :setf and :type

1 0

RE: [slime-devel] Slime hanging on foreign function calls with Lispworks
by Shawn Nicholson 05 Jul '05

05 Jul '05

Well, My question can be disregarded. I see in the known problems document that this issue does not currently have a known reason or solution. Thanks, Shawn -----Original Message----- From: Shawn Nicholson Sent: Wednesday, June 29, 2005 11:21 AM To: slime-devel(a)common-lisp.net Subject: [slime-devel] Slime hanging on foreign function calls with Lispworks Hello, I am a new user to slime and have run into something I can't seem to figure out. I am running Lispworks 4.4.5 Professional and Slime 2005-4-27 (LispWorks Port 1525 PID 220). I am attempting to run some code which calls some foreign functions however any attempt to do so causes Slime to hang. The windows click does not happen at all. Any ideas on what I'm missing (or what settings I have incorrect) that would prevent me from making FLI calls? Thanks, Shawn (in-package :cl-user) (defparameter *segman-dll* "C:\\Projects\\SegMan\\hemets\\src\\segman.dll") (fli:register-module *segman-dll*) (fli:define-foreign-function (c_single_click "c_single_click" :source) ((pause :int)) :result-type :void) (defun single-click (&optional (pause 0)) (format t "Executing single click.~%") (c_single_click pause)) (defun test-click () (single-click)) _______________________________________________ slime-devel site list slime-devel(a)common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel

3 6

[slime-devel] M-p/M-n doesn't move to the note in cvs slime and xemacs
by Raymond Toy 05 Jul '05

05 Jul '05

After updating slime to the CVS slime version of 2005-05-16 to get the GC message changes, I notice that M-p/M-n no longer seems to move the the previous/next compiler note when in the Lisp buffer. The compiler notes seem to be highlighted correctly, but M-p/M-n always say no next note. This is with cmucl 2005-05 snapshot, and xemacs 21.5-b20. This combination with slime from Feb or so was working just fine. I can look into this if someone gives a few pointers on where to look. Thanks, Ray

4 11

[slime-devel] Re: It's not just me! [was: CLISP on Windows?]
by Hoehle, Joerg-Cyril 05 Jul '05

05 Jul '05

Karsten Poeck wrote: >Unfortunately the cygwin version now breaks with >WARNING: DEFUN/DEFMACRO: redefining function GETPID in [...] >*** - FFI::LOOKUP-FOREIGN-FUNCTION: A foreign function "getpid" does not exist It appears that the code in CVS provides a different implementation of getpid than what I sent to the slime list a few weeks ago. I don't know why there was a change. I saw no mention of a problem in this mailing list since. The current CVS is broken in some aspects (portability, FFI declaration, missing interface). Did my code break something? Karsten, could you please remove the def-call-out for both unix and win32 in swank-clisp.lisp and uncomment the #+(or) form below it, and report your findings? I think that my own code, in a win32-clisp (not cygwin) 2.33.1 or older, without the WIN32 package, will define getpid to the constant -1. If this causes a problem, please tell me and I can change that. Possibly processes will not be interruptible. clisp >2.33.2 should work. I appreciate it when new code still works with old versions of other programs. Regards, Jorg Hohle.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel July 2005