slime-devel September 2010

slime-devel@common-lisp.net

19 participants
35 discussions

[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

[slime-devel] Small xemacs change to make arglists work
by Raymond Toy 03 Sep '10

03 Sep '10

With lots of help from Tobias on #lisp, I've discovered an issue with slime-forward-cruft. I think xemacs doesn't understand "[:space:]" in skip-chars-forward. Changing that to "[\\s]" makes arglists work. The issue shows up when trying to get autodoc[1] to show the arglist for "(cos". This failed because it was looking for "os". The above fix makes it work again. Thanks to Tobias for helping me find this. Ray [1] Yes, I know slime-autodoc is disabled for xemacs, but I have a verbatim copy of eldoc from emacs that runs just fine on xemacs, so I hacked slime-autodoc not to error out when loaded for xemacs.

2 2

[slime-devel] C-c C-k, swank-compile-file, and compile-file's failurep
by Tobias C Rittweiler 03 Sep '10

03 Sep '10

Should C-c C-k try to load a resulting fasls file ALWAYS? Should it only do so if COMPILE-FILE did not return T as failurep? >From glancing, SBCL's and CMUCL's swank backends do the latter. Most other backends use an implementation dependent :LOAD keyword argument to COMPILE-FILE which I haven't checked what their semantics are on this matter. I wouldn't be surprised if the differ. The thing is that I sometimes want the first behaviour (early stage of development), sometimes the latter (precious state in the image). If C-c C-k always loaded, you could get the other behaviour by using C-c M-k instead (compile only) and C-c C-l afterwards if compilation didn't fail. If C-c C-k regarded failurep, you could force loading afterwards by C-c C-l. So both behaviours are available. I just pledge for consistency across backends. -T.

3 3

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

03 Sep '10

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2135 slime/ChangeLog:1.2137 --- slime/ChangeLog:1.2135 Wed Sep 1 09:18:55 2010 +++ slime/ChangeLog Fri Sep 3 03:25:19 2010 @@ -1,3 +1,20 @@ +2010-09-03 Helmut Eller <heller(a)common-lisp.net> + + For C-c C-k, ask before loading possibly broken fasl files. + + * slime.el (slime-compilation-result): Add 2 slots: loadp and + faslfile. + (slime-compilation-finished): Use them to load the faslfile. + * swank.lisp (:compilation-result): Add 2 slots. Use keyword + constructor. + (compile-file-for-emacs): Return loadp and faslfile to Emacs. + (collect-notes): Pass loadp and falsfile along. + +2010-09-02 Stas Boukarev <stassats(a)gmail.com> + + * swank-cmucl.lisp: #-cmu19 -> #+cmu18, cmu18 is allegedly the + oldest supported CMUCL. + 2010-09-01 Stas Boukarev <stassats(a)gmail.com> * swank-sbcl.lisp (background-save-image): add #-win32, because it Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.409 slime/contrib/ChangeLog:1.410 --- slime/contrib/ChangeLog:1.409 Sat Aug 21 17:34:12 2010 +++ slime/contrib/ChangeLog Fri Sep 3 03:25:24 2010 @@ -1,3 +1,7 @@ +2010-09-03 Helmut Eller <heller(a)common-lisp.net> + + * swank-kawa.scm (%%runnable): Update for changes in SVN version. + 2010-08-21 Stas Boukarev <stassats(a)gmail.com> * slime-fuzzy.el (slime-fuzzy-choices-buffer): XEmacs compatibility.

1 0

[slime-devel] Update swank-cmucl for cmucl 20
by Raymond Toy 02 Sep '10

02 Sep '10

Here is a small patch for swank-cmucl. Basically, treats cmu19 and cmu20 as the same. I'm not sure what effect this has, but it doesn't break anything that I can tell. In particular read-into-simple-string is no longer defined, but it's not defined in cmucl 20 either, so it wasn't used anyway. Ray

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel September 2010