- slime-devel - mailman3.common-lisp.net

[slime-devel] Daily ChangeLog diff
by Helmut Eller 17 Sep '10

17 Sep '10

Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.416 slime/contrib/ChangeLog:1.418 --- slime/contrib/ChangeLog:1.416 Thu Sep 9 04:28:21 2010 +++ slime/contrib/ChangeLog Thu Sep 16 15:19:26 2010 @@ -1,3 +1,16 @@ +2010-09-16 Stas Boukarev <stassats(a)gmail.com> + + * swank-arglists.lisp (print-variable-to-string): Use + without-printing-errors when printing the value. + Reported by Tobias C. Rittweiler on lp#628945. + +2010-09-16 Christophe Rhodes <csr21(a)cantab.net> + + Image display support for the REPL. + + * slime-media.el: New file. + * swank-media.lisp: New file. + 2010-09-09 Stas Boukarev <stassats(a)gmail.com> * swank-c-p-c.lisp (longest-compound-prefix): Wrong arguments for

1 0

[slime-devel] Character completion for cmucl
by Raymond Toy 17 Sep '10

17 Sep '10

Here is support for character name completion for cmucl. The attached file can be placed at the end of swank-cmucl.lisp. This code will go into the next snapshot of cmucl, so the bulk of the code is conditionalized on lisp::unicode-complete not existing. Because the name space is so large, completion is done kind of incrementally. (If full completion were done, think of how many completions there would be for #\CJK!) The name is completed upto the next "piece". As you type more, more pieces are added. The completions might look a little weird, but they (usually) expand to the correct value eventually. (This is an artifact of how cmucl stores the character names and the desire to do this incrementally.) There's at least one bug: #\ne shows NE as a completion, but that's not a valid name. But the completion also shows the valid continuations. I hope this is useful to someone. Ray

1 2

[slime-devel] C-C C-m both for macro and compiler-macro expansion
by Tobias C Rittweiler 15 Sep '10

15 Sep '10

Would anyone mind, or find it utterly confusing, if C-c C-m would try to expand compiler macros? -T.

2 1

[slime-devel] q on slime-to-lisp-filename-function
by Mirko Vukovic 15 Sep '10

15 Sep '10

Hi, I updated slime to 2010-09-09 from 2010-04-something, and I was unable to start swank because of the following error: PARSE-NAMESTRING: syntax error in filename "C:\\program files\\emacs23.1\\...swank.lisp" at position 2 I was able to fix it by setting slime-to-lisp-filename-function to #'identity (based on an old post from 2008). Is that the correct fix? Thanks, Mirko

2 1

[slime-devel] [CfP] 4th European Lisp Symposium, Hamburg, March 31 - April 1st, 2011
by Didier Verna 13 Sep '10

13 Sep '10

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~~ + Submission Deadline: January 09, 2011 + Author Notification: February 06, 2011 + Final Paper Due: February 28, 2011 + Symposium: March 31 - April 1st, 2011 Authors of accepted research contributions will be invited to submit an extended version of their papers for journal publication. Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism & Efficiency". We especially invite submissions in the following areas: + Parallel and distributed computing + Code generation for multi-core architectures + Code generation for HTM + Large and ultra-large systems + Optimization techniques + Embedded applications Contributions are also welcome in other areas, including but not limited to: + Context-, aspect-, domain-oriented and generative programming + Macro-, reflective-, meta- and/or rule-based development approaches + Language design and implementation + Language integration, inter-operation and deployment + Development methodologies, support and environments + Educational approaches and perspectives + Experience reports and case studies Technical Program: ~~~~~~~~~~~~~~~~~~ We invite submissions in the following forms: * Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. * Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=els2011 Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna - EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller - Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[slime-devel] Daily ChangeLog diff
by Helmut Eller 10 Sep '10

10 Sep '10

Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.415 slime/contrib/ChangeLog:1.416 --- slime/contrib/ChangeLog:1.415 Mon Sep 6 23:05:17 2010 +++ slime/contrib/ChangeLog Thu Sep 9 04:28:21 2010 @@ -1,3 +1,9 @@ +2010-09-09 Stas Boukarev <stassats(a)gmail.com> + + * swank-c-p-c.lisp (longest-compound-prefix): Wrong arguments for + longest-common-prefix. + Reported by Peter Stirling. + 2010-09-07 Stas Boukarev <stassats(a)gmail.com> * swank-c-p-c.lisp: s/delimeter/delimiter/, correct spelling.

1 0

[slime-devel] [investigation] Font lock, reader macros and SLIME repl
by Anton Kovalenko 09 Sep '10

09 Sep '10

Hello SLIME developers, Both in the lisp-mode and in slime REPL, there is currently one major thing that Emacs isn't getting right: constructs using reader macros like #P"/home/" and #2A((1 0) (0 1)) are regarded as two sexps instead of one. E.g. command for wrapping a sexp may turn #P"/home/" into (#P)"/home/", etc. It gets even more awful with paredit-mode (that I prefer to use), but the problem is noticeable even without it. I have investigated one possible solution to it, and here are the results. First, I decided to limit the scope of solution to some predefined "shape" of reader macro: for starters, when #\# is used as dispatch macro character, and its reader function calls READ to get the sexp following #[numarg]<char>. This is the case with all standard reader-macros and many implementation-specific and user-defined ones. Furthermore, I discarded the possibility to consult SWANK for the buffer's *readtable* (SWANK doesn't *know* it, anyway). To get right behavior for #P, #2A and the like, the most appropriate syntax for all macro-characters seems to be `expression prefix': we want Emacs to regard the whole #P thing as it would regard a quote, backquote or comma. Let's use the feature of font-lock mode in modern emacsen: syntactic keywords (in a nutshell, it's when a code used for text-coloring is [ab]used to add syntax-table properties to some text fragments). `parse-sexp-lookup-properties' set to true causes the sexp machinery to look into syntax-table properties of individual characters. Let's add a syntactic keyword to lisp-mode: (defun aak:add-lisp-reader-macros-syntactic-keyword () "Register # numarg macro-character as a font lock syntactic keyword, turning it into expression prefix." (set (make-local-variable 'parse-sexp-lookup-properties) t) (set (make-local-variable 'font-lock-syntactic-keywords) '(("\$\\W\\|$\$\\#\$[0-9]*[A-Za-z]\$" (2 "'"))))) (add-hook 'lisp-mode-hook 'aak:add-lisp-reader-macros-syntactic-keyword) With the hook above, any lisp-mode buffer with font-lock mode enabled gets good enough navigation/wrapping/unwrapping for previously misinterpreted items. I decided to leave macro-characters handled by this regexp to [A-Za-z], because normal behavior of reading the following sexp can't really be expected from other characters: readtable additions along the lines of #"something" and #{something} are also popular, and we can't get _them_ right without knowing a concrete syntaxt they expect. Another decision that has its merits is to limit it further to _standard_ macro-characters only. Now I wanted the same thing to be active for slime-repl mode. The only obstacle was that slime-repl mode is currently font-lock-unfriendly: when some faces are set programmatically and some left to font-lock, the programmatically-set faces should use font-lock-face property instead of face property (the latter gets overridden by font-lock results). A workaround that I use currently is the following advice to add-text-properties: (defadvice add-text-properties (before aak:slime-propertize-with-font-lock-face activate) (when (eq 'slime-repl-mode major-mode) (let* ((props (ad-get-arg 2)) (face (getf props 'face))) (when face (push face props) (push 'font-lock-face props) (when (memq 'face (getf props 'rear-nonsticky)) (push 'font-lock-face (getf props 'rear-nonsticky))) (ad-set-arg 2 props))))) When in slime-repl mode, it copies face property to font-lock-face property, and also makes it rear-nonsticky when face is requested to be. It's the only part that really touches SLIME, and I think it would better insert font-lock-face property itself, together with face property (don't forget rear-nonstickyness). This duplication (face => font-lock-face) does no harm when font-lock mode is disabled, but enables slime-repl buffer to be used with font-lock enabled as well. Another hook to enable font-lock mode in slime buffers: (defun aak:enable-font-lock-for-slime-repl () "Enable font lock mode in slime REPL buffer." (font-lock-fontify-buffer) ;; don't know why it's needed.. (font-lock-mode 1)) (add-hook 'slime-repl-mode-hook 'aak:add-lisp-reader-macros-syntactic-keyword) (add-hook 'slime-repl-mode-hook 'aak:enable-font-lock-for-slime-repl) NB. The problem that I'm trying to solve is even more important for slime-repl buffers, where incorrect sexp wrapping tends to break _presentations_ apart. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia

4 7

[slime-devel] C-c tab Completion
by Peter Stirling 09 Sep '10

09 Sep '10

Hi, I use the C-c tab completion from slime-fancy, but after updating slime tonight I get a stack trace like the following when I try to expand e.g.: hun -> hunchentoot: (This is running on sbcl 1.0.42.25) invalid number of arguments: 2 [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR] Restarts: 0: [*ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING {AFDBD51}>) Backtrace: 0: (SWANK::LONGEST-COMMON-PREFIX ("hunchentoot" "hunchentoot:"))[:EXTERNAL] 1: (SWANK::LONGEST-COMPOUND-PREFIX ("hunchentoot-asd:" "hunchentoot:") #\-) 2: (SWANK:COMPLETIONS "hun" "MUSIC") 3: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:COMPLETIONS "hun" '"MUSIC") #<NULL-LEXENV>) 4: (SWANK:EVAL-FOR-EMACS (SWANK:COMPLETIONS "hun" '"MUSIC") "MUSIC" 78) 5: (SWANK::PROCESS-REQUESTS NIL) 6: ((LAMBDA ())) 7: ((LAMBDA ())) 8: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {AFE50A5}>) 9: ((FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {AFE50A5}>) 10: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #1=#) (*STANDARD-INPUT* . #) (*TRACE-OUTPUT* . #1#) (*ERROR-OUTPUT* . #1#) (*DEBUG-IO* . #2=#) (*QUERY-IO* . #2#) ...) #<CLOSURE (LAMBDA #) {AFE50B5}>) 11: (SWANK::HANDLE-REQUESTS #<SWANK::CONNECTION {CE81349}> NIL) 12: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {AFE5085}>) 13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK362]367)) 14: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 15: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300)) 16: (SB-THREAD::CALL-WITH-MUTEX ..) 17: (SB-THREAD::INITIAL-THREAD-FUNCTION) 18: ("foreign function: call_into_lisp") 19: ("foreign function: funcall0") 20: ("foreign function: new_thread_trampoline") 21: ("foreign function: #xB7FB796E")

2 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 07 Sep '10

07 Sep '10

Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.413 slime/contrib/ChangeLog:1.415 --- slime/contrib/ChangeLog:1.413 Fri Sep 3 20:32:14 2010 +++ slime/contrib/ChangeLog Mon Sep 6 23:05:17 2010 @@ -1,3 +1,13 @@ +2010-09-07 Stas Boukarev <stassats(a)gmail.com> + + * swank-c-p-c.lisp: s/delimeter/delimiter/, correct spelling. + +2010-09-07 Stas Boukarev <stassats(a)gmail.com> + + * swank-c-p-c.lisp (untokenize-completion): Take an optional + argument "delimiter". + (longest-compound-prefix): Pass delimiter to untokenize-completion. + 2010-09-04 Stas Boukarev <stassats(a)gmail.com> * swank-fuzzy.lisp (*fuzzy-completion-...*): Change defparameter

1 0

[slime-devel] Daily ChangeLog diff
by Helmut Eller 04 Sep '10

04 Sep '10

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2137 slime/ChangeLog:1.2138 --- slime/ChangeLog:1.2137 Fri Sep 3 03:25:19 2010 +++ slime/ChangeLog Fri Sep 3 18:29:43 2010 @@ -1,3 +1,8 @@ +2010-09-03 Stas Boukarev <stassats(a)gmail.com> + + * slime.el (slime-forward-cruft): Use " \t\n" to match whitespaces + instead of [:space:], XEmacs compatibility. + 2010-09-03 Helmut Eller <heller(a)common-lisp.net> For C-c C-k, ask before loading possibly broken fasl files. Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.410 slime/contrib/ChangeLog:1.413 --- slime/contrib/ChangeLog:1.410 Fri Sep 3 03:25:24 2010 +++ slime/contrib/ChangeLog Fri Sep 3 20:32:14 2010 @@ -1,3 +1,22 @@ +2010-09-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-fuzzy.lisp (*fuzzy-completion-...*): Change defparameter + to defvar for easier customization. + +2010-09-03 Stas Boukarev <stassats(a)gmail.com> + + * slime-repl.el (slime-search-property-change): XEmacs may return + nil on previous/next-single-char-property-change, don't pass it to + goto-char. + +2010-09-03 Stas Boukarev <stassats(a)gmail.com> + + * slime-repl.el (slime-repl-mode-end-of-defun) + (slime-repl-mode-beginning-of-defun): Take an optional argument + which specifies how many defuns it should move. GNU Emacs catches + wrong-number-of-arguments condition and does this by itself, but + XEmacs doesn't. + 2010-09-03 Helmut Eller <heller(a)common-lisp.net> * swank-kawa.scm (%%runnable): Update for changes in SVN version.

1 0