slime-devel January 2006

slime-devel@common-lisp.net

54 participants
50 discussions

[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 21 Jan '06

21 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

Re: [slime-devel] Re: SBCL restart-frame
by Mészáros Levente 20 Jan '06

20 Jan '06

> levy> On the other hand return from frame is already supported for SBCL > in > levy> SLIME. > > levy> And if I got it right the above statement also means that return > from > levy> frame works the same "somewhat bad" way. I mean returning from the > levy> frame of bar (in the debugger) the value of *a* will return 1 > instead of > levy> 0. > > levy> Am I right? > > Yes. However, there are two environments here: > > 1) The environment used to compute arguments for the command. Possibly > this > should be the environment of the frame, but it doesn't matter too much > as > long as the person debugging the code knows which environment is used. > > 2) The environment used to execute the command. For "restart frame", this > should be the original environment of the frame, otherwise functions > like > FOO will fail to perform correctly. For "return from frame" it doesn't > really matter which environment is used, becase no user code is > executed. > > __Martin I see your points, but the last statement I think is not quite true. Return from the frame can evaluate an expression which might or might not refer to user code. Actually it is very usefull to call the original function with different parameters for example. In which case the environment problem still exists. Of course if one is aware of that then the issue can be safely avoided. levy ________________________________________________________________ Elégedetlen helyzetével? Új kihívásokra vágyik? Állást Keres? - Mi segítünk! www.jobpilot.hu

2 1

RE: [slime-devel] Re: SBCL restart-frame
by Mészáros Levente 20 Jan '06

20 Jan '06

> > Is it really this simple? > > Not quite. The restarted function will be run in the wrong dynamic > environment. For example: > > (declaim (optimize (debug 2))) > > (defvar *a* 0) > > (defun foo (a) > (let ((*a* (1+ *a*))) > (/ 2 a))) > > (defun bar () > (print *a*) > (foo 0)) > > When you call BAR, it'll print 0 and then call FOO, which will signal > an error. If we now restart BAR, the dynamic binding for *A* that FOO > established will still be visibile, and it'll print 1 instead. On the other hand return from frame is already supported for SBCL in SLIME. And if I got it right the above statement also means that return from frame works the same "somewhat bad" way. I mean returning from the frame of bar (in the debugger) the value of *a* will return 1 instead of 0. Am I right? levy ________________________________________________________________________ Képkidolgozás már bruttó 25,- Ft-tól! FotoMarket Online Fotóáruház - már 5 éve az Ön fotószolgálatában: www.fotomarket.hu

2 1

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

19 Jan '06

Hi, I thought about alternatives and rejected them. Probably this patch is just fine as is and it should not raise an error when Emacs uses UTF-8 or anything and clisp was only built with 8bit strings --without-unicode. 2006-01-14 Joerg Hoehle <hoehle(a)users.sourceforge.net> * swank-clisp (find-encoding): work in a 8bit clisp w/o #-UNICODE. --- swank-clisp.lisp.orig 2005-11-12 00:43:43.000000000 +0100 +++ swank-clisp.lisp 2006-01-14 13:17:08.000000000 +0100 @@ -122,7 +122,9 @@ (:iso-latin-1-unix "iso-8859-1") (:utf-8-unix "utf-8") (:euc-jp-unix "euc-jp")))) - (ext:make-encoding :charset charset :line-terminator :unix))) + (ext:make-encoding :charset (if (member :unicode *features*) + charset :default) + :line-terminator :unix))) (defimplementation accept-connection (socket &key (external-format :iso-latin-1-unix) The idea in the present patch is that (untested) the same set of slime.fas files might possibly work in both builds of clisp: with and without unicode. But you'd need to compile from the 8bit version. Regards, Jorg Hohle.

2 1

Re: [slime-devel] [patch] Make it possible to keep FASL files in source directory
by Nathan Bird 19 Jan '06

19 Jan '06

This makes swank no longer asdf loadable. E.g. http://paste.lisp.org/display/15792 The problem is that UCW depends upon swank, but just stating that dependency in the asd is no longer good enough. All the swank packages aren't there until the load-swank function is called, and since files in UCW reference the swank package we get a reader error. The name "SWANK-BACKEND" does not designate any package. Can we please make swank continue to be fully loaded by default? Maybe make several ASD files, one similar to the current swank.asd that just makes swank-loader available, and another that also loads a file that does (swank-loader:load-swank) ? Any thoughts? Nathan Bird

2 1

[slime-devel] How to cleanly update from CVS
by Jonathon McKitrick 19 Jan '06

19 Jan '06

Hi all, I was bitten earlier this week when I updated and found that swank no longer started and required changed to .sbclrc to fix. Is there a recommended procedure to follow when I cvs up to make sure an update goes cleanly? -Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"

3 2

[slime-devel] How should I test multithreaded SBCL code using SLIME?
by Glenn Ehrlich 18 Jan '06

18 Jan '06

All, I'm experimenting moving over a body of code from LispWorks to SBCL and I've got some multithreaded code. When using LW, I'd just start up a LW core image on a command line, manually start up swank, then do slime-connect a couple of times, and use the 2 repls to experiment / debug the multithreaded code. Specifically, I've got a shared queue that waits when empty; I'd call the dequeue in repl 1, see that it properly waits, then enqueue in repl 2 and ideally see the enqueue return in repl 1; crude, but simple. I try doing the same thing in SBCL. I start up SBCL in a shell, start up swank, and I can start up the 1st repl with slime-connect. When I attempt a 2nd slime-connect, emacs loses the connection to SBCL and I get this in the shell running SBCL: WRITE: (:return (:ok (:pid 6102 :style :spawn :lisp-implementation (:type "SBCL" :name "sbcl" :version "0.9.8") :machine (:instance "localhost.localdomain" :type "X86" :version "Intel(R) Pentium(R) 4 CPU 2.80GHz") :features (:acl-compat :cl-ppcre it.bese.arnesi.mopp::have-mop :split-sequence :asdf :sb-thread :ansi-cl :common-lisp :sbcl :unix :sb-doc :sb-test :sb-package-locks :sb-unicode :sb-source-locations :ieee-floating-point :x86 :elf :linux :gencgc :stack-grows-downward-not-upward :c-stack-is-control-stack :stack-allocatable-closures :linkage-table :os-provides-dlopen :os-provides-dladdr :os-provides-putwc) :package (:name "COMMON-LISP-USER" :prompt "CL-USER"))) 1) WRITE: (:open-dedicated-output-stream 32783) READ: "(:emacs-rex (swank:connection-info) \"COMMON-LISP-USER\" :repl-thread 1) " DISPATCHING: (:EMACS-REX (SWANK:CONNECTION-INFO) "COMMON-LISP-USER" :REPL-THREAD 1) ;; Event history end. ;; Connection to Emacs lost. [ ;; condition: The value NIL is not of type SB-THREAD:THREAD. ;; type: TYPE-ERROR ;; encoding: :ISO-LATIN-1-UNIX style: :SPAWN dedicated: T] <sbcl is locked, so I hit control-c and get this:> debugger invoked on a SIMPLE-CONDITION in thread #<THREAD "initial thread" {A66D379}>: interrupted at #XB7FFF402 Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Return from SB-UNIX:SIGINT. 1: [ABORT ] Exit debugger, returning to top level. (SB-UNIX::SIGINT-HANDLER #<unavailable argument> #<unavailable argument> #.(SB-SYS:INT-SAP #XB7B9C5FC)) 0] I'm running SBCL 0.9.8, slime from cvs of 12/27/2005, and Fedora Core 4. I've got a function for starting up swank: (defun start-swank (&key (port swank::default-server-port) (style swank:*communication-style*) (dont-close t)) "Start the SLIME swank server, listening on PORT. Multiple connections are allowed." (swank:create-server :port port :style style :dont-close dont-close)) and I call it with default arguments, (start-swank). Is it possible to drive SBCL like I mentioned at the top with LispWorks and if so, how do I do it? Thanks! Glenn Ehrlich

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel January 2006