slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] Making potentially problematic changes
by Ian Eslick 27 Jan '06

27 Jan '06

I've updated the inspector in swank.lisp to support metaclass based slot-value overrides. This requires use of the mop functions slot-boundp-using-class and slot-value-using-class (and adding them to the swank-mop package) which may not be consistent over the various versions. Since the inspector is rather central to slime, I don't want to commit this change directly (and don't have write permissions to slime CVS (ieslick(a)common-lisp.net). Is there a proper procedure for testing a change like this if you don't have all the test configurations available locally? Thank you, Ian

2 1

[slime-devel] newbie REPL questions
by funkyj＠gmail.com 24 Jan '06

24 Jan '06

I'm not sure how the whole SLIME development cycle is suppose to work. One of the things that is confusing me is that selecting various options in SLDB causes the REPL to lose its connection with the inferior lisp, requiring me to do 'M-x slime' to reconnect. Here is an example: ;; starting slime for the first time in this emacs session M-x slime ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; messages Connecting to Swank on port 2369.. Process bridge is installed Connected. Hack and be merry! ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; repl buffer shows ; SLIME 2006-01-20 CL-USER> x ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; sldb clisp/0 buffer appears EVAL: variable X has no value [Condition of type SYSTEM::SIMPLE-UNBOUND-VARIABLE] Restarts: 0: [USE-VALUE] You may input a value to be used instead of X. 1: [STORE-VALUE] You may input a new value for X. 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [ABORT] ABORT Backtrace: 0: #<SYSTEM-FUNCTION EVAL> 1: #<COMPILED-FUNCTION SWANK::EVAL-REGION> 2: #<COMPILED-FUNCTION SWANK::LISTENER-EVAL-1> 3: #<COMPILED-FUNCTION #:|273 275 (DEFINTERFACE CALL-WITH-SYNTAX-HOOKS (FN) ...)-31-3-1-1|> 4: #<COMPILED-FUNCTION SWANK::CALL-WITH-BUFFER-SYNTAX> 5: #<COMPILED-FUNCTION SWANK:LISTENER-EVAL> 6: #<SYSTEM-FUNCTION EVAL> 7: #<COMPILED-FUNCTION SWANK::EVAL-FOR-EMACS-1> 8: #<COMPILED-FUNCTION #:|472 477 (DEFINTERFACE CALL-WITH-DEBUGGER-HOOK (HOOK FUN) ...)-52-3-1-1|> 9: #<COMPILED-FUNCTION SWANK::EVAL-FOR-EMACS> 10: #<COMPILED-FUNCTION SWANK::READ-FROM-EMACS> 11: #<COMPILED-FUNCTION SWANK::HANDLE-REQUEST-1> 12: #<COMPILED-FUNCTION #:|472 477 (DEFINTERFACE CALL-WITH-DEBUGGER-HOOK (HOOK FUN) ...)-52-3-1-1|> 13: #<COMPILED-FUNCTION SWANK::CALL-WITH-CONNECTION-1> 14: #<COMPILED-FUNCTION SWANK::CALL-WITH-REDIRECTED-IO> 15: #<COMPILED-FUNCTION SWANK::MAYBE-CALL-WITH-IO-REDIRECTION> 16: #<COMPILED-FUNCTION SWANK::CALL-WITH-CONNECTION> 17: #<COMPILED-FUNCTION SWANK::HANDLE-REQUEST> 18: #<COMPILED-FUNCTION SWANK::SIMPLE-SERVE-REQUESTS-2> 19: #<COMPILED-FUNCTION SWANK::SIMPLE-SERVE-REQUESTS> 20: #<COMPILED-FUNCTION SWANK::SERVE-REQUESTS> 21: #<COMPILED-FUNCTION SWANK::SERVE-CONNECTION> 22: #<COMPILED-FUNCTION SWANK::SETUP-SERVER-SERVE> 23: #<COMPILED-FUNCTION SWANK::SETUP-SERVER> 24: #<COMPILED-FUNCTION SWANK:START-SERVER> 25: #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; type '3' (abort) into the sldb buffer ;; the following minibuffer message appears: Lisp connection closed unexpectedly: exited abnormally with code 256 ;; type 'enter' in repl buf and I see: if: Not connected. Use `M-x slime' to start a Lisp. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Starting slime again with M-x slime works fine but takes a long ;; time. It seems a lot of actions cause the lisp connection to close unexpectedly. Is this normal? Should I just ignore it and restart slime? Restarting slime after each "mistake" (I make a lot of them) is rather tedious. FYI: I'm using clisp from cygwin: GNU CLISP 2.35 (2005-08-29) (built on winsteingoldlap.ad.alphatech.com [10.41.52.182]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -I. -x none -lintl libcharset.a libavcall.a libcallback.a -lreadline -lncurses -liconv -L/usr/local/libsigsegv-cygwin/lib -lsigsegv -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED libsigsegv 2.2 libiconv 1.9 Features: (REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX CYGWIN) C Modules: (clisp i18n syscalls regexp) Installation directory: /usr/lib/clisp/ User language: ENGLISH Machine: I686 (I686) jcano-lt.jnpr.net [192.168.1.103] and GNU Emacs 21.3.1 (i386-mingw-nt5.1.2600) of 2004-03-10 on NYAUMO SLIME, as you can see is the CVS head I checked out 2006-01-20. Thanks in advance, --jfc

2 2

[slime-devel] shortcuts to OPs other than ASDF's own
by Walter C. Pelissero 24 Jan '06

24 Jan '06

I was wondering if this patch could be considered for inclusion in SLIME. It allows to write repl shortcuts for operations not belonging to the ASDF package simply prefixing the operation string with the package name. diff -c -r1.92 swank-backend.lisp *** swank-backend.lisp 23 Oct 2005 08:47:54 -0000 1.92 --- swank-backend.lisp 24 Jan 2006 13:51:45 -0000 *************** *** 313,319 **** (error "ASDF is not loaded.")) (with-compilation-hooks () (let ((operate (find-symbol "OPERATE" :asdf)) ! (operation (find-symbol operation-name :asdf))) (when (null operation) (error "Couldn't find ASDF operation ~S" operation-name)) (apply operate operation system-name keyword-args)))) --- 313,323 ---- (error "ASDF is not loaded.")) (with-compilation-hooks () (let ((operate (find-symbol "OPERATE" :asdf)) ! (operation (let ((colon (position #\: operation-name))) ! (if colon ! (find-symbol (subseq operation-name (1+ colon)) ! (subseq operation-name 0 colon)) ! (find-symbol operation-name :asdf))))) (when (null operation) (error "Couldn't find ASDF operation ~S" operation-name)) (apply operate operation system-name keyword-args)))) -- walter pelissero http://www.pelissero.de

1 0

[slime-devel] New startup behavior
by Jonathon McKitrick 24 Jan '06

24 Jan '06

Hi all, I noticed that since the recent change in startup behavior, slime seems to compile a lot more code each time it is started. My older laptop takes a lot longer to start than before, when sbcl used asdf to load it, IIRC. Is there a way to avoid this delay with each start? -Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"

1 0

[slime-devel] SLIME and CLX and CMUCL "lock up" problem
by David Trudgett 23 Jan '06

23 Jan '06

Hi everyone, I was directed to this mailing list by a fellow on comp.lang.lisp, so hopefully this is the right place to ask. I've been using SLIME for a while now (I'm just a Lisp newbie, however), and it has been really great. Since doing some CLX programming in CMUCL, I've noticed a lot of "freeze ups" where the Lisp subprocess just goes off and does its own thing and has to be sent a TERM signal, which means I also have to restart SLIME. Is this a known conflict between the CLX library and SLIME? If any of you guys has a suggestion about how I might work around this, or ideas about what else might be causing problems, it would be greatly appreciated. My environment is: GNU Emacs 21.4.1 SLIME 2005-12-27 (from CVS) CMUCL 19a CLX X Library MIT R5.02, (the one that comes with CMUCL) Thanks for doing a great job with SLIME! Bye for now, David -- David Trudgett http://www.zeta.org.au/~wpower/ Hickory Dickory Dock, The mice ran up the clock, The clock struck one, The others escaped with minor injuries.

1 0

[slime-devel] [Feature Request:] keeping history for several macroexpansions in a row
by Tobias C. Rittweiler 23 Jan '06

23 Jan '06

Hi Slime-hackers, I'd like to suggest keeping a stack-like history for several macroexpansions in a row such that you can easily go back one macroexpansion after you've macroexpanded a form /inside/ the macroexpansion buffer. Erm, yeah, sure, here's a small example: Let's say you have two macros like these: (defmacro with-foo (() &body body) `(flet ((foo (arg) arg)) ,@body)) (defmacro with-bar ((arg) &body body) `(with-foo () (prog1 (foo ,arg) ,@body))) Ah, well, hopefully yours will do something less stupid. Anyway, let's further say that you want to macroexpand (`C-c RET') the following form: (with-bar ('foobar) (let ((x 1)) (* x x))) the macroexpansion buffer should pop up containing something like (WITH-FOO NIL (PROG1 (FOO 'FOOBAR) (LET ((X 1)) (* X X)))) Now you want to expand that form as well, so you place point before `(WITH-FOO' and press `C-c RET' again, now the old expansion buffer disappears and instead a new one pops up in some other window. While it's cool that macroexpansion works from within the macroexpansion buffer, the current behaviour is unfortunately somewhat annoying, because upon exit from the expansion buffer (via pressing `q'), -- while the old buffer constellation is nicely recovered as of before any macroexpansion --, the point won't afterwards be in the same window where you started macroexpansion. (Split your emacs horizentally, on top the REPL, on the bottom the slime-scratch buffer; now paste the above form in the REPL and do a macroexpansion there, slime-scratch will be replaced by the expansion buffer; now expand again from inside the macroexpansion buffer, a new expansion buffer will be placed into the REPL window; there press `q' and the point will be within slime-scratch although you started from the REPL.) I suggest a slightly different behaviour when expanding a form from within the macroexpansion buffer: the old buffer should be reused and you should be able to go back to the previous macroexpansion (like what `l' does in the inspector.) Additionally I'd like to suggest a way to macroexpand into a newly created macroexpansion buffer that's independant from a possibly other expansion buffer that got created prior. The purpose is simply for side-by-side comparasions of the same macro but that was modified in between. Finally, I'm often hit by not releasing the control-key fast enough such that a `C-c C-RET' key sequence is generated. Maybe that could be made an alias for `C-c RET'? Keep up the great work! -*- tcr

2 1

[slime-devel] Auto-nag: slime link verifier failed
by root＠common-lisp.net 23 Jan '06

23 Jan '06

You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at clo-devel(a)common-lisp.net Thanks!

1 0

[slime-devel] CVS version can't find swank?
by Jonathon McKitrick 21 Jan '06

21 Jan '06

I *just* updated from cvs and now sbcl and slime cannot find swank. (require 'swank) returns nil, and swank:create-server fails of course. Any ideas? -Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"

4 7

Re: [slime-devel] clisp without unicode patch
by Hoehle, Joerg-Cyril 21 Jan '06

21 Jan '06

Helmut Eller wrote: >The user has to choose an encoding that actually works I had hoped for auto-detection, or at least reasonable defaults and consistent settings. E.g. I found a message in the *inferior-lisp* buffer ("event-history end") saying that iso-8859-1 was used. However, the buffer's mode line says "u". Same for the slime-repl and *slime-events* buffers. Same for many other buffers in Emacs (e.g. Dired), while Lisp source buffers mostly say "--", i.e. ASCII. .slime-history.eld says -*- utf-8-unix (but so far there's only ASCII therein). This is Emacs-21.4 on a Ubuntu Breezy i386 with the default clisp-2.35 (not self compiled) -- with #+UNICODE. How comes? Is that 1/3 a bug-report? >because the packet length field isn't interpreted >correctly and the payload of the packet will be truncated I wasn't aware slime is sending packets. I thought it's all Lisp data, readable with READ :) I think it's then ok to modify the patch to assert :iso-8859-1 on a non unicode clisp. And let the user figure out how to set this??? Regards, Jorg Hohle.

3 2

Re: [slime-devel] Re: CLISP SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 20 Jan '06

20 Jan '06

Luke Gorrie <luke(a)bluetail.com> writes: > Bill_Clementson(a)peoplesoft.com writes: > > > My previous SLIME installation was a CVS install from 4/18. I've just taken > > the latest CVS install and the CLISP SLIME implementation (under Windows) > > breaks. Here is the error: > > > > COERCE: #<MACRO #<COMPILED-CLOSURE SWANK::DEFSLIMEFUN>> cannot be coerced > > to type FUNCTION > > [Condition of type SIMPLE-TYPE-ERROR] > > I can reproduce this but I've no idea what is causing it. It /looks/ > like someone is trying to call defslimefun as a function rather than a > macro, but I don't see where it could happen -- the macro is declared > at the top of the only file that refers to it. > > I did fix a different but similar problem that I got under CLISP. It > seems like I had to swap the order of a couple of macros, one of which > expanded into into code that calls the other, but that surely can't be > the reason. > > > Backtrace: > > 0: EVAL frame for form (SWANK:CREATE-SWANK-SERVER 4007) > > Mine actually gives an empty backtrace (!). I fixed the Elisp-side to > handle that incase it helps someone more CLISP-savvy find the problem. Has anybody had any luck in finding the source of this problem? CLISP still breaks for me in the latest CVS. I have had a look at all of the DEFSLIMEFUN's that were modified since 4/18 (the previous CVS version that I had which was working ok with CLISP) and haven't found any obvious clues. Any suggestions on how I might debug this issue as it occurs at startup during the slime-connect processing in Emacs (after CLISP has started up successfully)? - Bill

5 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel