slime-devel June 2009

slime-devel@common-lisp.net

35 participants
59 discussions

[slime-devel] Daily ChangeLog diff
by Helmut Eller 06 Jun '09

06 Jun '09

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1779 slime/ChangeLog:1.1781 --- slime/ChangeLog:1.1779 Thu Jun 4 05:08:06 2009 +++ slime/ChangeLog Fri Jun 5 15:58:53 2009 @@ -1,3 +1,15 @@ +2009-06-05 Helmut Eller <heller(a)common-lisp.net> + + Don't clutter compiler messages with source positions. Especially + stuff like "In an anonymous lambda form inside an anonymous lambda + form inside an anonymous lambda form inside FOO: Undeclared free + variable X" is not helpful. + + * swank-openmcl.lisp (compiler-warning-short-message): New GF. + (handle-compiler-warning): Use it. + + (disassemble-frame): Print current PC. + 2009-06-04 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-dispatch-event [:emcas-rex]): Don't clutter

1 0

[slime-devel] Installing swank
by Patrick May 05 Jun '09

05 Jun '09

I'm having trouble installing swank locally. I had it working by adding a symbolic link from /usr/local/src/slime/swank.asd to /usr/ local/asdf-install/site-systems/swank.asd, but that required write access to /usr/local/src/slime for temporary files. Is there a way to specify a different directory for those? I then tried this: (make-package :swank-loader) (defparameter swank-loader::*source-directory* "/home/pjm/slime/") (defparameter swank-loader::*fasl-directory* "/home/pjm/slime/") (load "/home/pjm/slime/swank-loader.lisp") (setq swank:*use-dedicated-output-stream* nil) (swank:create-server :port 4005 :dont-close t) But it resulted in: > Error: Reader error on #<BASIC-FILE-CHARACTER-INPUT-STREAM ("/home/ pjm/ccl-init.lisp"/4 ISO-8859-1) #x300040F05A0D>, near position 714, within "etq swank:*use-dedic": > Reference to unknown package "SWANK". > While executing: CCL::SIGNAL-READER-ERROR, in process listener(1). Is there a way to install via asdf locally? (Clozure CL 64-bit on CentOS, if that matters.) Thanks, Patrick

3 3

[slime-devel] REPL problems
by Stephen Lee 05 Jun '09

05 Jun '09

I have manage to install SLIME (latest cvs), Emacs 22.3 and SBCL 1.0.22 on Windows. Managed to configure and start SLIME. But REPL is not working. after i entered the code and press enter the code dosen't seem to execute Example CL-USER>(+ 1 2) <enter> No 3 is displayed I set up SLIME on Ubuntu before and it works so is it a windows thing? I followed the instructions here http://common-lisp.net/pipermail/slime-devel/2008-May/007331.html _________________________________________________________________ NEW! Get Windows Live FREE. http://www.get.live.com/wl/all

5 11

[slime-devel] slime-disconnect kills remote ccl
by Patrick May 04 Jun '09

04 Jun '09

Hi, I started Clozure from the command line on a remote machine and loaded swank with (asdf:oos 'asdf:load-op :swank). Since I'd just updated to the CVS head for slime, it recompiled. I got these warnings: ; Warning: These Swank interfaces are unimplemented: ; (ACTIVATE-STEPPING ADD-FD-HANDLER ADD-SIGIO-HANDLER CALLS- WHO ; FIND-SOURCE-LOCATION REMOVE-FD-HANDLERS REMOVE-SIGIO- HANDLERS SAVE-IMAGE ; SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN SLDB-STEP-INTO SLDB-STEP-NEXT ; SLDB-STEP-OUT) ; While executing: SWANK-BACKEND::WARN-UNIMPLEMENTED-INTERFACES, in process listener(1). NIL Are they important? I then started swank: ? (setq swank:*use-dedicated-output-stream* nil) NIL ? (swank:create-server :port 4005 :dont-close t) ;; Swank started at port: 4005. 4005 ? I set up an ssh tunnel for port 4005 and was able to connect and use the Clozure image from Emacs on my local box. When I was done I used M-x slime-disconnect and it killed the Clozure image with this error: ;; swank:close-connection: Unexpected end of file on #<BASIC-TTrace/ BPT trap Do I have something misconfigured? Thanks, Patrick

3 6

[slime-devel] What does swank do with streams?
by mikel evins 04 Jun '09

04 Jun '09

I realize the question in the subject line is not specific enough to elicit useful answers. I need to ask some questions about how swank uses streams, so that I can ensure that forthcoming changes to CCL coexist with swank in a civil fashion. Unfortunately, I don't know enough about swank to ask intelligent questions. Basically, what's happening is that we're working on some changes to CCL that are intended to make inspection and debugging of running Cocoa apps more reliable and convenient. In the course of that work, some of the Clozure hackers have noticed inputs and outputs going to unexpected places when swank servers are running. They're complaining about streams getting snatched out from under them. Doubtless this is because we don't properly understand what swank is doing with the streams. I frankly don't know how to frame an intelligent question on this subject, because I don't know enough about what swank is trying to accomplish and how it's going about it. So, what questions should I ask? My goal is to ensure that CCL controls the standard streams in a way it can rely on, while still allowing a swank server to be created and run. If you guys would help me zero in on the right questions to ask you about swank's operation, I'd appreciate it. -me

2 4

[slime-devel] Hints needed on why "Process inferior-lisp hangup" occurs
by Willem Rein Oudshoorn 02 Jun '09

02 Jun '09

I need some hints to start figuring out why I regularly get a "Process inferior-lisp hangup" in my *inferior-lisp* buffer, but I do not have clue where to start. Situation: * OS: Mac OS X * Lisp version: sbcl 64bit 1.0.28 and ccl 1.3-r12156M (64bit) * Slime version: CVS version as of today. "Reproduction Scenario" 1 Start slime with one of the two lisp implementaitons mentioned above 2 Open "/dev/tty.NXT-DevB-1", which is a serial blue tooth connection to a Lego NXT brick. 3 Turn of the Lego NXT brick (the other side of the serial connection) After this, I get the "Process inferior-lisp hangup" in the *inferior-lisp* buffer. In contrast, if I do not run this through slime, but just run it from a terminal the lisp implementaiton is not killed. I assume that the serial bluetooth connection is closed from the other side and that that somehow closes also the slime connection. But I don't know why, if this is normal, and how to change this behaviour. All hints are appreciated. Wim Oudshoorn.

3 5

[slime-devel] Connection to Emacs lost. condition: junk in string
by Andrei Stebakov 02 Jun '09

02 Jun '09

Recently when I evaluate a relatively big function in slime (more that 6 lines of code) I lose connection with swank. I tried Emacs with different versions and slime with different versions, so I don't know where else I can look for an error. Could it be something with network on this particular workstation? The stack is following (for the particular function what failed to evaluate): close-connection: junk in string " (setf" ... deinstall-fd-handler ;; Event history end. ;; Backtrace: (0 ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {A11068D}>)) (1 (SWANK::SAFE-BACKTRACE)) (2 (SWANK::MAKE-SWANK-ERROR #<SWANK::SWANK-ERROR {C9492F9}>)) (3 ((FLET #:LAMBDA2855) #<SWANK::SWANK-ERROR {C9492F9}>)) (4 (SIGNAL #<SWANK::SWANK-ERROR {C9492F9}>)[:EXTERNAL]) (5 (ERROR #<SWANK::SWANK-ERROR {C9492F9}>)[:EXTERNAL]) (6 ((FLET #:LAMBDA2855) #<SB-INT:SIMPLE-PARSE-ERROR {C750239}>)) (7 (SIGNAL #<SB-INT:SIMPLE-PARSE-ERROR {C750239}>)[:EXTERNAL]) (8 (ERROR SB-INT:SIMPLE-PARSE-ERROR)[:EXTERNAL]) (9 (PARSE-INTEGER " (setf")[:EXTERNAL]) (10 (SWANK::READ-PACKET #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}>)) (11 (SWANK::DECODE-MESSAGE #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}>)) (12 (SWANK::WAIT-FOR-EVENT/EVENT-LOOP (OR (:EMACS-REX . SWANK::_) (:EMACS-CHANNEL-SEND . SWANK::_)) T)) (13 (SWANK::WAIT-FOR-EVENT (OR (:EMACS-REX . SWANK::_) (:EMACS-CHANNEL-SEND . SWANK::_)) T)) (14 (SWANK::PROCESS-REQUESTS T)) (15 (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL)) (16 (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL)) (17 (SB-SYS:WAIT-UNTIL-FD-USABLE 10 :INPUT NIL)) (18 (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}>)) (19 (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}> NIL :EOF)) (20 (SB-IMPL::ANSI-STREAM-READ-CHAR #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}> NIL :EOF #<unavailable argument>)) (21 (SB-IMPL::ANSI-STREAM-READ-SEQUENCE ..)) (22 (READ-SEQUENCE ..)[:EXTERNAL]) (23 (SWANK::READ-CHUNK #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}> 627)) (24 (SWANK::READ-PACKET #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}>)) (25 (SWANK::DECODE-MESSAGE #<SB-SYS:FD-STREAM for "a socket" {C5C30E1}>)) (26 (SWANK::WAIT-FOR-EVENT/EVENT-LOOP (OR (:EMACS-REX . SWANK::_) (:EMACS-CHANNEL-SEND . SWANK::_)) T)) (27 (SWANK::WAIT-FOR-EVENT (OR (:EMACS-REX . SWANK::_) (:EMACS-CHANNEL-SEND . SWANK::_)) T)) (28 (SWANK::PROCESS-REQUESTS T)) (29 ((LAMBDA ()))) (30 ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C74E74D}>)) (31 (SWANK::CALL-WITH-BINDINGS ..)) (32 (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {C5C3A79}> #<CLOSURE (LAMBDA #) {C74E74D}>)) (33 (SWANK::HANDLE-REQUESTS #<SWANK::CONNECTION {C5C3A79}> T)) (34 (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL)) (35 (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL)) (36 (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)) (37 (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {C10A859}>)) (38 (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {C10A859}> NIL #:EOF-OBJECT)) (39 (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {C10A859}> NIL #:EOF-OBJECT #<unused argument>)) (40 (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {9137511}> NIL #:EOF-OBJECT #<unused argument>)) (41 (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {9137511}> NIL (NIL) T)) (42 (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {9137511}> NIL (NIL) NIL)) (43 (READ #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {9137511}> NIL (NIL) NIL)) (44 (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {9137511}> #<unavailable argument>)) (45 (SB-IMPL::REPL-FUN NIL)) (46 ((LAMBDA ()))) (47 (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {C5AAAFD}>)) (48 (SB-IMPL::TOPLEVEL-REPL NIL)) (49 ((LABELS SB-IMPL::RESTART-LISP))) ;; Connection to Emacs lost. [ ;; condition: junk in string " (setf" ;; type: SWANK::SWANK-ERROR ;; encoding: NIL style: :FD-HANDLER dedicated: NIL] Thank you, Andrei

2 1

[slime-devel] [PATCH] Output redirection in the SIMPLE-SERVE-EVENTS case.
by Samium Gromoff 01 Jun '09

01 Jun '09

Good day folks, The following patch fixes the *standard-output* not being redirected into the *slime-repl* buffer on SBCL/win32 specifically, and in all cases when connection communication style is NIL, in general. The problem appeared in the CVS commit dated 2008-12-24 11:14:06, which moved environment capture past the point where the event handlers were entering the binding of the stream variables, which is set from the environment. The fix was tested on Linux/x86/SBCL-1.0.22 and MinGW/SBCL-1.0.28.43. commit 87cd4f6167e0b9695a279d8c64e1f4876a001e0a Author: Samium Gromoff <_deepfire(a)feelingofgreen.ru> Date: Wed May 13 23:44:52 2009 +0400 Capture stream globals before the request servers are called. diff --git a/swank.lisp b/swank.lisp index a0646c2..90418f2 100644 --- a/swank.lisp +++ b/swank.lisp @@ -1408,6 +1408,16 @@ The processing is done in the extent of the toplevel restart." :serve-requests #'simple-serve-requests)) ))) (setf (connection.communication-style c) style) + (initialize-streams-for-connection c) + (with-struct* (connection. @ c) + (setf (@ env) + `((*standard-output* . ,(@ user-output)) + (*standard-input* . ,(@ user-input)) + (*trace-output* . ,(or (@ trace-output) (@ user-output))) + (*error-output* . ,(@ user-output)) + (*debug-io* . ,(@ user-io)) + (*query-io* . ,(@ user-io)) + (*terminal-io* . ,(@ user-io))))) (setf success t) c) (unless success @@ -1569,16 +1579,7 @@ NIL if streams are not globally redirected.") (defslimefun create-repl (target) (assert (eq target nil)) (let ((conn *emacs-connection*)) - (initialize-streams-for-connection conn) (with-struct* (connection. @ conn) - (setf (@ env) - `((*standard-output* . ,(@ user-output)) - (*standard-input* . ,(@ user-input)) - (*trace-output* . ,(or (@ trace-output) (@ user-output))) - (*error-output* . ,(@ user-output)) - (*debug-io* . ,(@ user-io)) - (*query-io* . ,(@ user-io)) - (*terminal-io* . ,(@ user-io)))) (maybe-redirect-global-io conn) (when (use-threads-p) (setf (@ repl-thread) (spawn-repl-thread conn "repl-thread"))) regards, Samium Gromoff

2 1

[slime-devel] Lispbox SLIME 2.0 version output goes to *inferior-lisp* buffer instead of to *slime-repl clisp-2.37* buffer on Windows XP Professional, Service Pack 3
by Benjamin L. Russell 01 Jun '09

01 Jun '09

The output of the following program solving the Towers of Hanoi problem in Common Lisp directs the output of the "format" statement to the "*inferior-lisp*" buffer instead of to the "*slime-repl clisp-2.37*" buffer on Windows XP Professional, Service Pack 3: >(defun hanoi (n) > (hanoi-helper n 'A 'B 'C)) > >(defun hanoi-helper (n source dest using) > (cond ((equalp n 1) (format t "Move disc from ~A to ~A.~%" source dest)) > (t (progn > (hanoi-helper (- n 1) source using dest) > (hanoi-helper 1 source dest using) > (hanoi-helper (- n 1) using dest source))))) When "M-x slime-redirect-inferior-output RET" is invoked in Lispbox Emacs, the output is redirected correctly, but so is the rest of the output to the "*inferior-lisp*" buffer. This is not a clean solution. Does anybody know how to get the above hanoi-helper procedure to direct the output of the "format" statement correctly to the REPL, instead of to the "*inferior-lisp*" buffer? (This point is probably not relevant, but I have reconfigured Lispbox to call my .emacs file using my existing GNU Emacs 22.3.1 installation.) -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

1 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel June 2009