slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] Patch: Put "SLIME Source Form" buffer into Lisp mode
by Matthias Koeppe 17 Jul '05

17 Jul '05

Another trivial patch. 2005-07-17 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * slime.el (slime-goto-location-buffer): Put "SLIME Source Form" buffer into Lisp mode. --- slime.el.~1.511.~ 2005-07-05 21:53:21.000000000 +0200 +++ slime.el 2005-07-17 17:25:03.000000000 +0200 @@ -4383,6 +4458,7 @@ ((:source-form string) (set-buffer (get-buffer-create "*SLIME Source Form*")) (erase-buffer) + (lisp-mode) (insert string) (goto-char (point-min))))) -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe

1 0

[slime-devel] Handling ^M and ^H characters output from ext:run-program?
by Jeff Cunningham 17 Jul '05

17 Jul '05

I posted the following question on comp.lang.lisp: I have this code embedded in a process I'm running: (ext:process-exit-code (ext:run-program "cdrecord" args :output *standard-output*))) and it works fine, except that the cdrecord utility (and many others) uses both backspace ^H and carriage return ^M to write updates to the screen. This makes a big mess in the slime-repl window ,as they aren't properly interpreted and so stuff spews out for miles before it finishes. Is there a way to capture these characters before they hit *standard-output* and interpete them so they either work correctly or are at least benign (i.e. convert carriage return to a linefeed, and any sequence of backspaces ^H^H^H^H^H^H^H with a linefeed)? One of the respondents pointed out that: "*STANDARD-OUTPUT* is bound to some Lisp stream maintained by SLIME, attached to an Emacs buffer. cdrecord was not designed to attach to an Emacs buffer, or to anything other than a terminal (or some program which emulates a terminal by understandin the control codes for moving your cursor around" Is there a way to still embed this program call within my lisp project so I can still run it in slime without this behavior? Thanks --Jeff Cunningham

3 8

Re: [slime-devel] Re: Handling ^M and ^H characters output from ext:run-program?
by Jeff Cunningham 16 Jul '05

16 Jul '05

On Sat Jul 16, 2005 at 01:15:03AM +0200, Edi Weitz wrote: > > That doesn't work without Lisp either: > > edi@miles:/tmp$ bash echo "Hello World" > tmp > /bin/echo: /bin/echo: cannot execute binary file > > Try this instead: > > (ext:run-program "bash" '("-c" "echo \"Hello World\" > tmp") :output *standard-output*) > > Actually, I was rather thinking about invoking a shell script: > > edi@miles:/tmp$ rm foo > edi@miles:/tmp$ cat foo.sh > echo "Hello World" > /tmp/foo > edi@miles:/tmp$ cmucl > * (ext:run-program "sh" '("foo.sh") :output *standard-output*) > > #<process 4501 :EXITED> > * (quit) > edi@miles:/tmp$ cat foo > Hello World > That works. Thanks! --Jeff

2 2

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

14 Jul '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.722 slime/ChangeLog:1.723 --- slime/ChangeLog:1.722 Wed Jul 6 18:31:56 2005 +++ slime/ChangeLog Thu Jul 14 11:15:46 2005 @@ -1,3 +1,7 @@ +2005-07-14 Helmut Eller <heller(a)common-lisp.net> + + * swank-allegro.lisp (find-external-format): Fix typo. + 2005-07-06 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-send-sigint): Use the symbol SIGINT stead of the

1 0

[slime-devel] Typo in swank-allegro.lisp
by shmargolis＠gmail.com 14 Jul '05

14 Jul '05

Hi. I am using Franz Allegro 7 on Mac OSX. The cvs source for swank-allegro.lisp has a mismatch between the argument name and the variable used in the body. I've appended a context diff that let me get past that point. Thanks for all the work that has gone into this. Steve - - - - - RCS file: /project/slime/cvsroot/slime/swank-allegro.lisp,v retrieving revision 1.74 diff -c -r1.74 swank-allegro.lisp *** swank-allegro.lisp 5 Jul 2005 20:30:59 -0000 1.74 --- swank-allegro.lisp 13 Jul 2005 17:35:24 -0000 *************** *** 59,65 **** (defun find-external-format (coding-system) #-(version>= 6) :default #+(version>= 6) ! (let* ((name (ecase external-format (:iso-latin-1-unix :latin1) (:utf-8-unix :utf-8-unix) (:emacs-mule-unix :emacs-mule)))) --- 59,65 ---- (defun find-external-format (coding-system) #-(version>= 6) :default #+(version>= 6) ! (let* ((name (ecase coding-system (:iso-latin-1-unix :latin1) (:utf-8-unix :utf-8-unix) (:emacs-mule-unix :emacs-mule))))

2 1

[slime-devel] controlling indentation of let forms
by ramb＠sonic.net 12 Jul '05

12 Jul '05

Is it possible to change how slime (is slime controlling the ident process??) indents let forms? I prefer a let to look like this: (let (var1 var2 var3 var4 var5 var6) ...) but its currently indented like this: (let (var1 var2 var3 var4 var5 var6) ...) Can I change this? Or is slime the wrong place to look? Thanks for any info. -Ram

4 4

[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

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